为什么 DDD 用于 CQRS 和事件溯源应用程序？

Question

I am just starting with the CQRS, Event Sourcing. While examining many frameworks, I have realized that one of the thing most of the frameworks assumed that our application is modelled based on the DDD principles. I am not sure but can anyone explain to me that how DDD, CQRS, and Event Sourcing are related to each other and why DDD is generally required for implementing the CQRS and Event Sourcing pattern?

Answer 1

why DDD is generally required for implementing the CQRS and Event Sourcing pattern?

Tradition.

Before being rebranded as "CQRS", the same collection of ideas wore the label "Distributed Domain Driven Design". Greg Young's early presentations were experience reports describing how he adapted the ideas published by Evans when designing an algorithmic trading system.

In effect, this means that most of the audience that discovers CQRS and Event Sourcing have already been convinced that Domain Driven Design is a good idea.

They are different ideas, though; the CQRS pattern might be useful even when you aren't doing event sourcing.

can anyone explain to me that how DDD, CQRS, and Event Sourcing are related to each other

Event sourcing is really a pair of ideas

• changes should be first class citizens in our model
• our authoritative data model should be a sequence of changes (aka a history)

This kind of data model is great for writes (just append a new change on the end of the list), and has the additional benefit that edits are non-destructive; all of the information added to the system is still there, so you can easily time machine back to understand what things looked like prior to some change.

But histories suck for low latency query. Therefore: caches - we'll pre-compute the answers to some questions, and stick them in a property bag.

Now we have two models: the history, and the cache. And what is CQRS?

CQRS is simply the creation of two objects where there was previously only one -- Greg Young 2010

Answer 2

I don't think it's only tradition . When designing a system that would be using events as state transitions, the most useful approach is getting away from CRUD-style events (SomethingCreated, SomethingUpdated, etc), and model the actual behaviour instead. That's where Event Sourcing comes very close to the foundational idea of DDD - rich Domain Models, expressed with Ubiquitous Language.

Also, when we design an event-sourced system, we put some effort into defining stream boundaries, so we don't get large transactions, we don't have multi-stream transactions, the average stream length is upper-bound, etc. All these concerns align very nicely with the tactical Aggregate pattern of DDD.

When people just shovel events to Kafka topics and project them to some databases, they essentially are not doing Event Sourcing, but implementing an event-driven system instead.