DDD

CQRS

ES

Code like the client talks

(wow dat mess)

Ubiquitous language

Client doesn't say:

"new pdf after postPersist or postUpdate"

Client says:

"on payment receival, send the invoice"

Use this vocabulary

(and stick with it)

Task Based

WRITE

ReceivePayment...

...Command

the command (handler) acts as the entry point (a controller!) in our domain model.

It is framework agnostic

...Controller

the controller is the one that glues framework to domain model.

It validates and creates a command based  on the  request

Command (handler) retrieve the write model instance, and calls methods on it.

Basta.

Maybe there is no need of a Command AND a controller after all ?

not always, so KISS

Some BS:

• command bus (sometimes)
• command handler (sometimes)
• AsyncCommandBusQueueHandlerFactoryBuilder

(wow, easy bro)

Write model writes only (genius)

Separate persistence

(Always) start from a single entry point:

An Aggregate Root (AR)

AR keeps consistency inside the aggregate

Since modification is only possible from an AR, it's the guardian

(of the galaxy)

Change through methods

that say something!

and keep encapsulation in the meantime

Remember: same vocabulary

Client says:

"toMoveHouse()"

Client doesn't say:

"entity->setNumber()->setStreet()->setCountry()"

Changes have Consequences

Events

Client doesn't say:

"postUpdate"

Client says:

"CustomerMovedHouse"

Listen

(not the voice of god)

AR emits events

that say something happened

Things a client understand, and so do you

Declarative

not

imperative

PaymentReceived

PS: naming events are hard,

it needs many "event stormings" with client

Listen, then DO

Implement listeners that listen to domain events

• generate pdf
• broadcast via websockets
• do heavy stuff async

READ

cool story bro, but atm we don't display anything

AR are not made to display things

Create a separate read model, optimized for reads

Implement a domain event listener that creates projections of what happened

Event Sourcing

not necessary

we can use a good old ORM for the writes and the reads (just separate them)

Two birds with one stone

domain events listeners

+

replaying events

Store each event

and from which AR it comes

Replay them on an empty instance, until you have your previous sate