Domain Driven Design: Tackling Complexity at the heart of Software by Eric Evans.

I don’t think I can clearly remember the first time I heard about DDD but I bought Domain Driven Design written by Eric Evans following the recommendation of a former colleague who always made a lot of sense when he talked about software so I decided to give it a shot.

First of all, I think this book has a great subtitle: Tackling Complexity in the Heart of Software. I really like this subtitle because it answers many questions I had when I was reading about application architecture like clean architecture, onion architecture, hexagonal architecture or ports and adapters.

All of those reference architectures has something in the middle called the domain. Turns out this is where you "put in the business rules". Ok great but how do you model those business rules? Turns out you can model those business rules / the heart of your application using DDD and the ubiquitous language. Using the ubiquitous language means integrating the terminology used by subject matter experts into the codebase to improve the quality of the software built. Using the ubiquitous language in a given context, you can model the key components of the business process you are trying to automate and the book provides a ton of patterns to help you model and structure the domain. There is a lot more to DDD then that but this book lays the groundwork for what DDD is.

This book is not an easy read though. You can feel that the author has a lot of experience and he tried to explain a lot of subtleties that can go completely under the radar for someone who is learning all this stuff from scratch. This book has helped me in my product owner role at least by building a glossary of the domain terms with my clients and sharing it with the development team to build a shared understanding. I really think that modeling the domain layer of a software application using the language of the subject matter experts makes it a lot clearer for everybody working on a project. However, sometimes the SME is not available or the domain is to new to have a mature terminology used to describe the business process so this is where you have to define and agree on terms before starting the project.

I would recommend this book but only as a reference you can keep close when you are learning DDD elsewhere. After reading this book, I felt the need to get another point of view to attack DDD from another angle so I bought Implementing Domain Driven Design from Vaughn Vernon but this will be the subject of another article.