Learning Domain-Driven Design (For Japanese readers)
What is this book
This book is about domain driven design, short for DDD.
If you are not familiar with ‘domain’, you can think domain as the core problem space or area of expertise that the business operates.
DDD is “an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain.”1
The distinctive point of DDD is starting with a deep dive into the business and its domain. This book provides tools to thoroughly explore the business and domain, as well as software design techniques to handle the complexity of the system.
Background
This book was published in 2021 — 18 years has passed since the book Eric Evans published ‘Domain-Driven Design’2 in 2003. In this book, you can learn more sophisticated and advanced practice of DDD which was enhanced by lots of talented engineers through the discussions for 18 years.
I highly recommend the engineers nowadays to start with this book for learning DDD.
What you can learn
This book can be divided into three parts:
1. Analyze Your Business Through DDD
2. Design and Implement Your System with DDD
3. Apply DDD Practically in Your Development Process
The first part of the book is more about understanding your business. I highly recommend this section to business planners in software companies.
The second part is geared towards software engineers, offering a powerful set of tools to tackle the complexity of core domains, supported by numerous sample code examples.
While DDD is a robust approach, applying it in practice requires effort and specific techniques. In the final part, you’ll learn practical methods like Event Storming to help you apply DDD effectively.
Why I read this book
In July 2024, I went on a business trip to our subsidiary company in the United States. Although the company had been acquired, the PMI3 had not yet been fully completed. The main purpose of this trip was to understand the business operations, workflows, and system architecture across the entire organization.
During the trip, I realized that my perspective on the business was too narrow.4 Some of the key questions I had not yet considered were:
How do we fully understand our business?
How do we design a system architecture that supports the entire business?
What components are necessary for our business to function?
How do we prioritize these components and allocate resources effectively?
This realization led me to study Domain-Driven Design (DDD). I bought this books as soon as I arrived Tokyo. The first chapter of this book was especially helpful in guiding me through these challenges.
In the era of generative AI, more and more aspects of software development are becoming automated. I believe that software engineers who deeply understand their own business will have a greater impact.
Post-merger integration — is the process of combining and rearranging businesses to materialize potential efficiencies and synergies that usually motivate mergers and acquisitions. (Wikipedia)
This is common among software engineers because one software engineer take cares of one system at the same time usually.