Book Rating : 5/10

Initially looking at the title of this book, I already expected it to be very heavily opinionated. It's not like you can tell someone how to design a domain model when every business has different needs and requirements. So at face value, I already expected to just skim through most of this book.

Chapters 1-4 are essentially very light on the topic itself. Just introducing the concepts of domains & subdomains in businesses, and how they relate to bounded contexts in software design. Honestly, it's very dry and if you have worked in a microservice-based engineering team before, it shouldn't be hard at all to follow along. So far I would say these few chapters can be skimmed through and the examples can also be skipped as it just discusses around different flavours of decoupling. This is to each their own in an organization though.

Chapter 5 introduces concepts of locking which I for one think if you have read part of Designing Data Intensive Applications (DDIA) you would have already been exposed to this concept. Chapter 6 talks about aggregates and state management which is a key concept in CQRS if the reader is not already familiar with it. Chapter 7 is rather juicy where the main notion revolves around event sourcing which I think is the crux of the entire DDD concept. Relating how event sourcing works similarly to WAL in databases, you would rather get the concept quickly. It's quite important in my opinion to understand this now as it evolves further into how replayability of events can help in reconstructing state in different bounded contexts.

Chapter 8 goes deeper into the topic of architectural patterns such as hexagonal architecture (ports & adapters), and CQRS. I think at least for the CQRS part, it was quite insightful because I personally had experience with asynchronous projections causing read models to have lag that was still tolerable in the trade off. However, since the projections was sort of an outbox pattern, downstream events still depended on the read model to be up-to-date which caused some issues.

Honestly, I skipped most of Chapter 9 because it was mostly about Saga pattern, outbox, and half of the things that didn't really interest me. Again, about Chapter 10 I have no clue what it was about, so nothing for me to note on here. I can't really tell you what I learned from Chapter 11 as well, but I think it has something to do with evolving legacy systems to DDD.

Chapter's Skipped

12 - Event Storming

13 - Domain-Driven Design in the Real World

14 - Microservices

Chapter 15 on Event Driven Architecture, and Chapter 16 on Data Mesh are worth skimming through. You may find some nuggets of knowledge in there. Data Mesh topic is mostly on OLAP vs OLTP if you are not already familiar with Data Engineering terminologies like fact tables, dimension tables, etc. It will help if you are interested in how medallion architecture is used for data pipelines. But since I was already familiar with the concepts of DAGs, ETL/ELT, I didn't find much value in it.

I skipped the 2 appendix chapters as well since it didn't seem to add much value to me. Overall I would say this book is just okay. If you are new to DDD concepts, it may be worth a read but I would suggest skimming through most of the chapters. If you are already familiar with microservices architecture, event sourcing, CQRS, and related patterns, I don't think this book would add much value to you. It's quite opinionated and I feel like the author is trying to push DDD as the ultimate solution to all software design problems when in reality, it's just one of many tools in the toolbox.