Recently I read a book titled Domain-Driven Design by Eric Evans. This wasn’t the first time I read this book but this time I realized that I had been totally wrong about domain-driven design.
I thought that the domain model consists of entities and value objects. In fact, I was obsessed with moving the domain logic to entities and value objects. I wanted to do it so bad that I ignored a crucial warning.
My code was cleaner than it used to be but I always felt that I was missing something.
When was I reading Domain-Driven Design for the second time, I realized what I had missed.
The Building Blocks of a Domain Model
My mistake was that I was so obsessed with entities and value objects that I forgot the other building blocks of a domain model.
Domain-Driven Design describes the domain model as follows:
A domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge. A diagram can represent and communicate a model, as can carefully written code, as can an English sentence.
However, reading this definition did not change my mind. In fact, when I read it I was feeling proud of myself because it seemed to verify that I was doing the right thing.
Then I started reading the second part of the book which talked about the building blocks of a model-driven design and the house of cards, which I had so carefully crafted, fell apart.
This part argues that the model-driven design has the following building blocks:
- Entities are objects which are defined by their identity. In other words, if an object has an identity which stays unchanged through its entire lifecycle, this object should be modelled as an entity.
- Value objects describe a property of a thing, and they don’t have their own identity or lifecycle. Often their lifecycle is bound to the lifecycle of an entity.
- Services contains operations that don’t belong to entities or value objects. If adding an operation to an entity or value object doesn’t feel natural to you, the odds are that you should add this operation to a service.
- Modules (Packages) are used to reduce cognitive overload. They give a developer the possibility to either investigate the internals of a single module without paying attention to other modules or investigate the relationships between modules without paying any attention to the implementation details.
- Aggregates are groups of objects which are treated as a single unit. Each aggregate has a root object which is used to access the other objects of the aggregate. Each aggregate has also a boundary which defines what objects belong to the aggregate in question.
- Factories are used to encapsulate the creation logic of an object or an aggregate. Factories are useful if the creation logic is complicated or reveals too much about the internal structure of the created object.
- Repositories are used to fetch entities from the used data storage and save the information of entities to it.
After I had finished the book, I had no other choice than to admit that I had no idea what domain-driven design really is.
The good news is that I still have got plenty of time to learn.
What Did I Learn?
The biggest thing which I learned by reading the Domain-Driven Design for the second time should be pretty obvious now but I did pick up a few other lessons as well:
- I understood the difference between the application services and the domain services. Application services coordinates the tasks and delegates work to domain objects. Domain services implement operations which don’t belong to entities or value objects. In other words, application services don’t contain business logic and domain services contain it.
- I understood that the domain model doesn’t have to be an exact copy of the reality. I can simply pick the parts of the reality which are useful to me and forget the rest. This seems obvious at first but it is also very easy to forget this.
My next step is to learn more about domain-driven design. To be more specific, I want to figure out how I can use these building blocks in my daily work. That is why I already ordered Implementing Domain-Driven Design by Vaughn Vernon.
What is your next step?
| Reference: | Domain-Driven Design Revisited from our JCG partner Petri Kainulainen at the Petri Kainulainen blog. |
Thanks for the very simple explanation of the building blocks. Am still confused about what logic goes in to domain and services. Am trying to create a POC implementing DDD, CQRS and Event store. I follow your blog as well. Once again, Thanks so far.