Domain-Driven Design in a nutshell

Domain-Driven Design, that’s what you use when you’re building Microservices. It’s a technique that can be used to cut monoliths into small bits, and it’s about Aggregates and Event-Sourcing. Or is it?

The book Domain-Driven Design by Eric Evans first appeared in 2004. It’s a book about communication, language, context, and models. And it’s a book about object-oriented programming and design patterns.

In essence, Domain-Driven Design is about creating a solution that reflects the problem at hand. It’s about designing software together. Not just the development team, but both the development-team and domain-experts.

Domain-Driven Design is about shared understanding.

The ubiquitous language

Assumptions are the mother of all screw-ups. You ask for a feature, the team thinks they understand, and they end up building something different.

Consider storing something in a database, for example. Sounds pretty straight forward… But somebody from the finance department may refer to their Excel-sheet when they say “database”. A developer probably means an instance of a SQL server. It’s the same word, but it has a different meaning.

Speaking the same language is the cornerstone of effective teamwork; Having a common understanding, having a language in which words mean the same thing to everybody in the team: A ubiquitous language.