DDD-CQRS-ES-Example | Domain Driven Design , CQRS , & Event Sourcing Example | Microservice library

But my question is more concrete: if I want to process new command (and apply new event), should I reconstitute entity from event stream (i.e. from write model and write db) and call its behavioral methods (which applies events to state) to handle business rules?

Yes.

Or just handle commands and events themselves, without having any write-model entity?

No.

The command handler lives in the application component; the business model lives in the domain component.

The motivation for keeping these components separated: making model replacement cost effective. What the domain experts care about, where the business gets its win, is the domain model. We don't expect to write the business model once and get it correct for all of time -- much more likely that we will learn more about how we want the model to work, and therefore be delivering improvements to the model on a regular basis. Therefore, its important that there not be a lot of drag to replace one version of the model with another -- we want the replacement to be easy; we want the amount of work required to make the change to be reflected in the business value we get.

So we want the good stuff separated from "the plumbing".

Keeping all of the business logic in the domain component gives you two easy wins; first, you don't ever have to guess about where the business logic lives -- whether the specifics of the use case are easy or hard, the business logic is going to be in the Order, not anywhere else. Second, because the business logic is not in the command handler, you don't have to worry about creating a bunch of test doubles to satisfy those dependency requirements -- you can test against the domain model directly.

So, we use handlers to reconstitute entities and calling their business logic methods, NOT to handling business logic itself?

Almost -- we use repositories to reconstitute entities and aggregates to handle the business logic. The role of the command handler is orchestration; it's the glue between the data model and the domain model.