Domain-Driven Design Distilled

---

Even though I never had the opportunity to strictly practice Domain Driven Design (DDD) in a professional context, I really enjoyed reading this book and I got much more out of it than I have expected.

It affected my day-to-day work in several ways.

I started thinking and modeling with domains and boundaries when architecting platforms, and I rethought the way I was engaging with stakeholders when working on projects.

I also realized that we are all already using some key DDD notions on a daily basis without even realizing it. Could it be by grouping together classes in namespaces or packages, defining the content of a database transaction or choosing how to name a new concept in a system.

The best way to sum up DDD is to use the definition given in the book:

DDD is a set of tools that assist you in designing and implementing software that delivers high value, both strategically and tactically. Your organization can’t be the best at everything, so it had better choose carefully at what it must excel.

Once we accept this definiton, it is easy to understand that all the tools introduced by DDD as they all aim to bring business experts closer to tech teams.

The author does a great job introducing key DDD principles:

• Bounded Context
• Ubiquitous Language
• Core domain / Subdomains
• Domain Expert
• Context Mapping
• Aggregates
• Domain events
• Event storming

Starting with strategic design first, the book does a great job explaining DDD outcomes and challenges on a high level before diving into technical details with tactical design.

As a matter of fact, it is a great resource to share with non-technical team member.

And for those who want to dive deeper into DDD, the original DDD book “Domain-Driven Design: Tackling Complexity in the Heart of Software” written by Eric Evans is a must.