Some quick points on DDD/CQRS/Event sourcing from my perspective. I've been involved in a project and have a number of concerns:<p>Firstly, the main drivers of this i.e. Greg Young/Udi Dahan/Particular are trying to sell a product and consultancy. While there is nothing wrong with this, there is a significant cost and the motivation to use this architecture is marketing driven rather than logical gains. Make sure it is appropriate for your organisation. 95% of organisations it probably isn't. It wasn't for ours but overzealous architecture proponents bought the marketing.<p>The cognitive load is immense compared to a smaller system architecture. Every change results in masses of friction, cost and time. Your agility will be destroyed pretty quickly. Also due to the cross-cutting concerns, there is no escape from it other than to port everything away.<p>The products to support it are generally immature, low quality and opinionated to the point that it's impossible to integrate cleanly on anything but a greenfield. Expect friction.<p>There are better gains to be had from changing your architecture to a purely service model (I hate the term, but microservices) and skip the whole concept.<p>However if there's one thing I have learned that Command-Query Separation is a good model for isolation. The Event Sourcing bit, not so much.
I really like Greg Young's talks on CQRS and Event Sourcing.<p>* <a href="https://www.youtube.com/watch?v=JHGkaShoyNs" rel="nofollow">https://www.youtube.com/watch?v=JHGkaShoyNs</a><p>* <a href="https://www.youtube.com/watch?v=KXqrBySgX-s" rel="nofollow">https://www.youtube.com/watch?v=KXqrBySgX-s</a>
I am a big user of both CQRS and Event Sourcing, but not in the very narrow sense implied by DDD/CQRS/ES advocates. In particular, there are two main tenets that I feel are not sufficiently justified.<p>One is the idea that commands are write-only (they are not allowed to return information). The reason for this restriction is fairly unclear, and there are several pieces of information that I believe can be legitimately returned:<p>- Has the command finished executing?<p>- Was it successful? If not, what was the exception thrown?<p>- If the command created something, what is that thing's identifier?<p>- For distributed systems, what is a vector clock after the command's execution?<p>Another idea is aggregates, especially the fact that each event is bound to a single aggregate and that two aggregates process their associated events independently. I can see how this can be useful, in a NoSQL-ish kind of way: by sacrificing the ability to enforce invariants across multiple aggregates, it becomes trivial to distribute event streams, to quickly compute the state of a single aggregate among millions, and to write to several aggregates in parallel without a global lock.<p>Still, sacrificing those invariants is costly. Many domains will have constraints on uniqueness (e.g. each e-mail address may belong to only one user) or relationship arity (e.g. each student may have at most one internship, each internship may have at most one student), and from my experience, expressing those constraints in an aggregate-based system usually ends up in:<p>- creating a "lock" aggregate with "Locked" and "Unlocked" events, or<p>- ignoring constraints and providing an user interface to manually resolve violations.<p>I would rather express simple constraints with simple code and have to work hard for optimizations later, than to have to write complex code just to solve an unconfirmed performance issue.
A nice resource for those exploring a completely event sourced, domain driven, responsibility segregated application.<p>I really do loath the acronyms.