[Book Reviews] Learning Domain-Driven Design

Hello everyone, Thank you for being interested in my review book blog again. This is another blog from the series related to my recently completed to read book called “Learning Domain-Driven Design” and this blog will give my feedback, recommendation, etc.

Disclaimer: I’m just a mid-level engineer who is interested in this book and hopes it will give me valuable information and make me better at my software engineer career path

Learning Domain-Driven Design

My physical book of Learning Domain-Driven Design

The book has separated to big 4 parts

1. Strategic Design — The part which tackles the What? and Why? questions
2. Tactical Design — The part which tackles the How? questions
3. Apply Domain-Driven Design in Practice — When you want to apply DDD in the team and workplace. How you can tackle and handle it?
4. Relationships to Other Methodologies and Patterns — If you are working in technical roles, this part relates to mapping the architecture to the DDD concepts.

My Summary of the book

The writer made the complex topics easier to understand and follow up on.

I would say as a technical guy the connect-the-dots moment starts to combine when you start reading about technical stuff and the writer may take the buzzword to the human word.

Part 1 — Strategic Design

The part focuses mostly on the business context and strategy of the business domain. I actually try to think more deeply for each paragraph and step (Since I want to learn more to convert the business to a technical part). Actually, I spent the most time here for thinking in strategic ways.

To summarize relate to the subdomain as quickly as possible

Core

• Activities the company performs differently from competitors to gain advantages.

Supporting

• Things the company does differently from competitors but not provide the advantages.

Generic

• Things all companies do the same way.

Part 2 — Tactical Design

The part where connect-the-dots has included in. They are between the business context and technical/technology context. Kind of the pattern knowledge for implementing the strategic design in the real world but not in the technologies context which I feel like that should be good for tech guy who would like to jump to the technology before we decided on the problems and solutions.

Part 3 — Apply Domain-Driven Design in Practice

Focusing on the collaboration between the business domain or even the team. The activities to make you understand in the business such as EventStorming which groups together to try to think in the green flow for the activity and so on. Apart from that, The way you can transform the subdomain into another

• Core => Generic
  When competitors have the same thing
• Core => Supporting
  When frequently changing and core subdomain not profitable as much as expected. So need simplification.
• Supporting => Core
  When increasing in complexity in supporting subdomain and feel we can make a profit, then the time to change.
• Supporting => Generic
  When we found open-source that has capabilities equal to or better in the market.
• Generic => Core
  Transform things that everyone uses into another market.
• Generic => Supporting
  When feel like open-source in the market cannot handle the subdomain anymore and revert back to use in-house.

The diagram told us how to transform subdomain

Part 4 — Relationships to Other Methodologies and Patterns

As a software engineer working mostly on the server-side (backend). In this part, I already have some knowledge including Microservice architecture, Event-Driven Architecture, and Data Mesh. I would say they’re easier for me to map the knowledge from past experience.

Example — Actually, the Microservice architecture is one of bounded contexts design which under domain-driven design. By the way, Not all boundary context is microservice architecture.

This part makes you clearer why we have it on daily basis including grouping the business domain into our own knowledge. Actually, The design decision is also based on the business domain.

Appendix

The enjoyable part is at the end. the hypothesis example experience, which gradually uses topics from the book, What succeeded, Why failed, and so on. So you are able to map the knowledge and topics from the book and the decision in each context.

I would say I give it 5 out of 5. I made some jokes about I give 4.8/5 due to making me sleep late. 😆 Actually, When things have been clearer, I feel more comfortable with the strategic information and able to combine the real-world use cases and software architecture as software engineering knowledge I already have.

There is no sense in talking about the solution before we agree on the problem, and no sense talking about the implementation steps before we agree on the solution.

— Efrat Goldratt-Ashlag

The other books that relate

From my point of view, If we need to learn more about each part of software architecture. This is the list I have thinking about.

Building Microservices, 2nd Edition

Building Event-Driven Microservices

Data Mesh

By the way, This is just my thought, I’m also broke for buying all of them. 😂

That’s it, I hope you enjoy it so far. See you in the following review book blogs. Furthermore, You can reach me at the below links.

Facebook: Thanaphoom Babparn
FB Page: TP Coder
LinkedIn: Thanaphoom Babparn
Linktree: https://linktr.ee/tpbabparn