DDD, CQRS and Event Sourcing
In preparation for a new gig I'm reading up on the terms Domain-Driven Design, Command-Query Responsibility Segregation, and Event Sourcing. Here are a list of useful texts and talks that I've discovered so far. If anything is missing please leave a comment.
- Eric Evans: What is a model? - "A model is not a UML diagram nor a certain layer of the software. [...]. It is a system of abstractions, it describes selected aspects of a domain, and can be used to solve problems related to that domain."
- Eric Evans: What I've learned since the book - slightly longer talk on Eric's findings since he co-authored the book on DDD.
- Eric Evans: Domain-Driven Design - As far as I can tell, the book on DDD. Haven't read it though.
- Command-Query Separation - although first defined in a book by Bertrand Meyer, Fowler makes a great job explaining CQS, the predecessor (sort of) to CQRS.
- Command-Query Responsibility Segregation - the term is coined by Greg Young (more links below), but again described well by Fowler. Builds on CQS. "At its heart is a simple notion that you can use a different model to update information than the model you use to read information." Moreover, "CQRS allows you to separate the load from reads and writes allowing you to scale each independently" is something I have studied previously, but don't remember using this term for it before. Neat! 1
- Udi Dahan: Clarified CQRS - Command-Query Responsibility Segregation "explained". Two significant components Dahan addresses that others have left out are collaboration and staleness. 2
- Greg Young's summary on CQRS - The "invetor's" own summary of the CQRS pattern. Perhaps the most straightforward explanation I've seen so far, but flies over some important aspects of what the pattern means for the data model in my opinion.
- CQRS pattern explained by MSDN - Good and detailed description of the pattern. Also includes a helpful section on when not to use it (and it has pictures).
- Fowler on Event Sourcing - The gist in one line: "Capture all changes to an application state as a sequence of events." Two notions I find particularly interesting are Temporal Query and Event replay. The post also includes a good list on some challenges with Event Sourcing.
- Event Sourcing explained by MSDN - The section on Performance, scalability and consistency is useful.
- EventStore - the basics of storing events rather than objects. "[...] data is not persisted in a structure but as a series of transactions."
- A deep look into the Event Store - talk by Greg Young from the Oredev conference, Nov 8, 2012.
- "Focus relentlessly on the core domain" - Evans
- "CQRS is not a top-level architecture. CQRS is something that happens at a much lower level, where your top level architecture is probably going to look more like SOA and EDA." - Young
- Aggregates are composed of smaller events. E.g., a purchase order contains line items
- I'd read Werner Vogel's eventually consistent post before, but stumbled upon it again and reread it. It's good.
- Examples in C# on CQRS and Event sourcing
- Akka and event sourcing - stumbled across a tweet from scalarconf and I spotted this presentation by Konrad Malawski.
- Description of EventStore's architecture
- "If you sat down with them [a customer], explaining the long-term value of having an archive of all actions in the system, and they said OK, build this into the system from the beginning, that would be fine." - Dahan
- Food for future thoughts: Reactive Design Patterns, Reactive Manifesto, SEDA, and Retrospective on SEDA.
 This may also mean that industry have come up with a marketable name for something researchers have been thinking about for a long time already.
 I got kind of frustrated/annoyed with this claim in Dahan's article: "How fast they get processed is a question of Service-Level Agreement (SLA) and not architecturally significant." To me it seems an SLA, determining much of a systems quality attributes, is definitely something architecturally significant. Maybe I just don't get what he's trying to say?