Book Review: Domain-Driven Design Distilled
A review of Vaughn Vernon's new book: Domain-driven Design Distilled and an overview of the Event Storming technique.
Join the DZone community and get the full member experience.Join For Free
The work of Vaughn Vernon is always admirable. His first book,Implementing Domain Driven Design (IDDD), was an excellent realization of DDD concepts. IDDD was the first book that forced me to buy it myself, instead of borrowing it from someone else. One difficulty that I had with this book was it took around six months for me to read it from cover to cover. I do not think that the length of the book was unnecessary, because it covers many design aspects that are related to good software design apart from DDD.
His new book Domain-Driven Design Distilled is a good read for people who are impatient to learn domain-driven design. It gives a quick walkthrough of different concepts that are part of DDD. Here, I will only discuss the part that is newly added in this short version of IDDD. If you are interested in the contents then you can follow the above link.
The chapter that caught my eye while skimming through the book was the last. Many DDD practitioners urge you to expedite the process of understanding business domain and translating the ubiquitous language used in that domain into system design. This chapter exactly tries to address that concern. It introduces a technique named Event Storming to help accelerating the process of understanding business domain. The technique requires both domain experts and software engineers to participate in the session equally, use sticky notes with different colors for each DDD concepts (Event, Command, and Aggregate), and strive to come up with a common understanding of business domain.
This technique is named Event Storming because it starts with brainstorming domain events in a business process. The essence of event storming is that it revolves around business process instead of nouns or objects. The event storming technique divides the whole process into five steps as mentioned below:
1. First step is to event storm domain events that defines a business process over a timeline.
2. Identify commands that triggers domain events in business processes. You are encouraged to keep adding new domain events that were not perceived in the previous step. Place each command before the respective domain event as shown below:
3. Identify Aggregate/ Entities on which commands are applied and domain events are triggered.
4. Encircle to define boundaries with arrows to show information flow. Eventually, this will create a Context Map containing different Bounded Contexts. The arrow lines represent domain events floating between Bounded Contexts.
5) Finally, create important views that are required for users to carry out their actions along with important user roles. This step should show only those views which requires more elaboration and care.
Disclaimer: All diagrams shown above are taken from the book itself.
The last part of the chapter discusses about how to manage DDD on agile projects using either Scrum, Kanban, or any other agile approach. The effort estimation techniques described in this chapter seem promising, but require some exercise to gain confidence.
In conclusion, I would say this book is definitely a good read for people who are new to DDD, but it still contains some new material for people who are already familiar with DDD. One most important concern that I think each domain driven design book ignores or perhaps does not discuss much about, is highlighting the importance of handling failures in case of asynchronous transaction among aggregates or between different bounded contexts. Perhaps cash tansfer among bank accounts as an example can be a good start. Life beyond Distributed Transactions is a good paper to read next. The terminologies used in this paper are bit different from DDD, but you will easily be able to correlate them once you are done reading. I highly recommend reading this paper along with this book. This will help you plot a complete picture of developing scalable enterprise applications using DDD concepts. You still have to refer to IDDD for a more detailed understanding as mentioned at many places in the book itself in various sections.
Opinions expressed by DZone contributors are their own.