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
