So time again for some education. This time I took the Domain Driven Design Immersion course that is held by Patrik Fredriksson (@weakreference) from Citerus.
I try to make a summery of the course here in my blog on a day to day basis.
Day 2
Today we are going to look at the building blocks of DDD and also discuss how we can involve the domain expert more to get a richer model.
So lets begin with a new building block.
Aggregate
- Transition boundaries – What must be saved in a single transaction to get consistency
- Distribution boundaries – What is distributed to other system or computers
- Concurrency boundaries – How is this effected by concurrency
Find cluster that are related regarding to consistency. We create the aggregate according to our reference scenarios.
Consistency boundaries
- Aggregates are always internally consistency
- Invariant apply at every transaction
- Aggregates are “eventual consistency” with each other
- Asynchronous update propagation through the system
- Limit interconnectedness
- Reference limited to aggregate roots
Use the Delete rule of thumb when designing aggregates.
Discuss deleting parts of the model and see how it is propagated through the model
Typically a reference from one aggregate to another occurs from the leaf of the referring aggregate to the aggregate root that being referred. Reference the aggregate by id instead of a real reference.
Distributed
The whole aggregate must be distributed and not only parts of it.
Concurrency
Aggregates are good for concurrency, since it is self-contained.
Reporting problem
To tackle a reporting problem when an aggregate design don’t suit a simple operation to get the result. Then a different model for reporting and operation can be used that is better suited for the reporting task.
Entities and Value Objects
- Entities has identity and are, usually, mutable
- Value Objects lacks identity and are, usually, immutable and uses side effect free functions
A good rule is to favour Value Objects over Entities.
Domain Events
Domain event represent something that have happen. Typical immutable with identity and a time stamp. They can spread to other models as well giving us the opportunity to have different models for the same thing that solves different problems. E.g. reporting vs. operation.
What do we get with Domain Events?
- Clearer, more expressive model
- Architectural options
- Representing the state of the entities
- Decoupling subsystem with events streams
- Enabling high-performance system (Greg Young style CQRS)
- Describes a history of what have happened in the model
Involving the domain experts
DDD calls for solutions from the domain experts. Therefore seek for a creative collaboration with the domain experts. Listen carefully of the language that the expert uses and adapt the ubiquitous language to that. Don’t try to shovel terms on the domain experts which they do not understand or use.
Try to retell what you think the domain expert has told you to see if that is a viable view of the domain. Mostly this will render in getting out even more information from the domain expert.
Distinguish decision making meeting from exploratory meeting. On an exploratory meeting try to broaden your view to get a better understanding of the whole domain, and not only the current problem. Be clear that it is an exploratory meeting so that the problems that is discussed are not expected to be in the next release.
Building blocks of model driven design
Entities
- Identity
- Interesting life-cycle
- Mutable
Value Object
- Defined by its values
- Irrelevant life-cycle
- Immutably
Services
- Not a thing
- Needed but not seems to fit in any entity or value object
Aggregate
- Cluster of Entities and Value Object
- Defined by its aggregate root (root entity)
Repositories
- Abstraction of the persistence layer
- Performs seeking and persistence of data
- Used for objects that needs global access, commonly aggregate roots
Modules
- Separate similar objects into a module
- Usually known as a package or namespace
Factories
- Creates complicated aggregates
Domain Events
- Events that occurred in the system
References
Effective Aggregate Design by Vaughn Vernon
This was all notes from day 2. Looking forward to day 3 now.
Disclaimer: This is my notes and my interpretation of the information. I can really recommend going the course.