CQRS, DDD, and Event Sourcing (ES)

...was the name of another talk I saw by Gabriel Schenker. In CQRS, conceptually you are changing a system much less than you are reading from it and thus a distinction may be made between commands and queries. Commands are the writes. You send them to the backend and you, at most, get back a pass or fail feedback affirmation/rejection. You do not need these to be particularly snappy in terms of performance. Queries are the reads. These are expected to have no side effects in the system. They should be nullipotent. Carrying this on to event sourcing, a model may be drawn in which there is a triangle wherein the points are the UI (called "the client" in Gabe's slides), the domain, and the read model. A fourth point on our triangle, making it sort of a diamond, would be the event store which keeps a history of what happened. Sequentially what happens between the actors is:

1. A command comes from the client to the domain.
2. Three things happens here. There are three arrows out from the domain to the three other pieces.
   • Acknowledge or not acknowledge is sent back to the client. I suppose in the event of not acknowledge the other two things herein don't occur and we are at the end of our process already. Yet, assuming acknowledge...
   • The read model is updated.
   • The event store is updated.
3. Next...
   • The client queries the read model and...
   • The event store acknowledges or not acknowledges the update from the domain.
4. A DTO (data transfer object) or DTOs are sent from the read model to the client.
5. Events from the event store may be replayed to the read model to get the history and big picture of what has gone on later on downstream of the process above.

The DDD part of the talk focused on Eric Evans ubiquitous language concept and in particular determining what the aggregates are in a domain which are sort of parallel to what the objects are in code... um, really they should be parallel. Your code should use the language you iron out in domain modeling. Aggregates have IDs and they can have simple properties such as string values. A customer, for example, can also have subobjects so to speak such as name, address, and phone number which are more than simple strings and perhaps get their own database tables, but these subordinate actors are only to be accessed by going through their parent and hence they are not aggregates in and of themselves. Aggregates will not have other aggregates nested inside of them.