Geek read: Learning Domain-Driven Design by Vlad Khononov

Intro

I’ve never been a DDD fanatic, but when I heard that Vlad Khononov’s new book was a great and easily digestible book on DDD with a modern touch, I had to read it. Here is a brief description of the book and what you can find in it.

Structure

The book is divided into easily digestible chunks that are not too long, as each section averages 16 pages in its 290 pages. There are 16 sections + closing words and appendix.

Thanks to this, it’s easy to concentrate and there’s hardly a dull moment. In case you do get distracted, the author has your back and at the end of each chapter there is a small set of “exercises” related to the section you have just read. Usually it’s a series of questions and an open-ended task. I love it. This is really great!

There is one thing I’m confused about and that’s WolfDesk. The author introduces a fictional company that is used as an example to explain concepts. But it’s rarely used in the book. It was strange to me because the questions in the exercises could be based on any company known to a wide audience, but it would be just great if all the concepts were explained through the prism of this imaginary company on specific cases. But it’s not a case.

What can I learn?

Modeling topics

• domains,
• subdomains with division to core, generic and supporting subdomains,
• knowledge building & discovery in your organization,
• building and importance of ubiquitous language,
• bounded contexts,
• communication patterns across bounded contexts (like ones described here),
• Event Storming

Subdomains are well described with their peculiarities and compared with each other. It’s not just theory, author goes through an exercise of identifying subdomains based on an example. Which is great.

There are many examples of importance of ubiquitous, building domain knowledge and discovering the domain that is typical for the books on the topic.

When it comes to bounded contexts I really liked that it was mixed into practical parts describing more technical concepts and there are lots of example across the book.

The part I really liked was the part about the evolution of domain types. It goes into analysis of how it could happen, how to spot it and how to navigate it.

Building blocks

The author describes a number of patterns for implementing business logic, with analysis and guidelines on when to use them, as well as their pros and cons.

• Transaction Script—with focus on minding transactions
• Active Record
• Value Object—with focus on modeling with ubiquitous language by dealing with primitive obsession
• Entity & Aggregates — with focus on consistency, transactions, boundaries and insights on defining them
• Domain Events
• Domain Services
• Event Sourcing — with a deep dive into the concept. We also get a FAQ section for important questions that may arise, as well as very interesting ones like: handling PII data and GDPR with append-only event stores.
• Outbox pattern — although it’s better described in this blog post
• Saga — not sure if that’s only my feeling, but in almost every technical book there is big part on Sagas
• Testing strategies

Architecture patterns

The author describes all the architectural patterns and building blocks listed below over several chapters, but it’s not just a technical introduction to the concepts. They’re all put into the context of DDD, and it’s really well described, with no fluff about their pros and cons.

Apart from that, the author provides some heuristics on when to choose which of these patterns, with decision trees that map together domain types, implementation patterns, test strategy and architectures.

I don’t think these decisions are that simple and can be solved with simple decision tree heuristics. I think they might create more confusion and raise more questions than answer.

Topics:

• Layered architecture,
• Ports & Adapters architecture,
• CQRS (yes, author explains how it’s different from Event Sourcing and how those two are terms are correlated :) )
• Microservices — with really nice take on domain← → microservice decomposition and their relation that was summed up by Khononov as:
  “All microservices are bounded contexts, but not all bounded contexts are necessarily microservices. In its essence, a microservice defines the smallest valid boundary of a service, while a bounded context protects the consistency of the encompassed model and represents the widest valid boundaries.”
• Event Driven Architecture — introduction to types of the events, how they are different from commands and writes about designing event-driven integrations keeping in mind potential coupling (functional, implementation & temporal) in allegedly decoupled integration.
• Data mesh — much shorter and comprehensive version of content that is available in great article by Martin Fowler

Summary

It’s a really good book. It’s well written and organised. The author does everything he can to teach you all the concepts. I definitely recommend it. I think people at all levels will find something valuable in it. I definitely did.

In my opinion, this book could be an eye-opener for many engineers and help them on their way to becoming better experts and mature engineers.

More info about the book can be found on O’Reilly website.