This was one of the most rewarding sessions for me. Eric Evans explained what he picked up and learned since he wrote the book, what parts that he realized was more important that he initially thought and what parts had been missing.
A missing building block: Domain Events
Something happened that domain experts care about.
what would make this clearer? A property or an event, what would be easier to hook into?
In his book, events wasn’t covered at all. In the DDD movement today though Events are carefully explored and popular in expressing things that happens that domain experts care about. They lead to clearer and more expressive models in that instead of adding more state, communicate that state shift with other objects to other objects. Which in terms open up some architectural options that wasn’t available before.
- Events that representing the state of entities (making the model clearer).
- Decoupling subsystems with event streams. Instead of creating tight coupling between subsystems you just send an event to tell others that might be interested what’s going on.
- Enabling High-performance systems. Evans stated that before he saw what Greg Young did with CQRS and event streams, he didn’t think DDD was suitable for this kind of systems. But with this take, it works.
What he learned about Aggregates
Aggregates are there to create a consistent boundary. In the book they are explained as a suitable boundary for transactions, distribution and concurrency. But over the years it has turned out that it’s also suitable to use as boundaries for properties and invariants. Again tying into the message he delivers over and over and over again, there is always more then one model
Things learned by Strategic design
There are a couple of concepts explained in Strategic Design. Some have turned out to be more important then others, Eric emphasizes that Core Domain, Context map and Bounded Context are really important but Large Scale hasn’t come up to often.
Context mapping on the other hand was much more important then he thought from the beginning. There are always multiple models which we need to accept and focus on the mapping between them instead of trying to make one that fits all. The one thing to remember is to be able to clearly communicate in what context a model id viable and have easy ways to communicate in which context we are talking.
This is where bounded context shines, they describe the conditions under which a particular model applies.
Missing Strategic Design concepts
Partners
Partners work on mutually dependent context in cooperation. This means that you share the responsibility of a context and teams will either succeed together or fail together.
Sometimes you just have to give up. BBoM is the notion of code in such a bad shape that trying to apply DDD on it doesn’t make sense at all. Michael Feathers talk in length about how to handle these scenarios. Within this boundary I’m not going to do any fancy stuff because it won’t work.
Object – relational
Storage should be handled as a separate context and thus a separate model. Use the strengths of Relational Modeling and don’t try to fit your objects directly into tables and relations. This makes sense when you think about it, if you represent a piece of data with different models in separate context, why would storage be any different?
Eric also mentioned that the work being put into NoSQL is very interesting for DDD practitioners since storage is just another context, and if that context can be expressed easier and be more out of the way of other context, it’s a good thing.
Reflections
I really liked this talk. Much because it validates thoughts I have (and have imposed on my team) around the “One model to rule them all”. There will always be different representations of a piece of data and Evans confirms this with very convincing rhetoric’s. Especially when it comes to putting the database in a separate context and thinking of it as a boundary.
It was also interesting to hear Eric’s thoughts on events and how they have become a first class citizen in Domain Driven Design. The trend in both design and architecture today is to use anonymous push via events and queues which actually is the driver behind a-not-yet published codeplex project which helps in setting up domain events and / or push things out in integration.
Watch this space for updates on that.
