A very short intro to software design using DDD

Domain Driven Design (DDD) has been practiced since Eric Evans first coined the term in his book in 2004, however, there are still many professionals involved in the software development process that have not yet heard the term. I will try to explain briefly what DDD is, by using an elevator pitch and a picture.

The pitch:

DDD is an approach to software development, a set of techniques and practices to aid the process of defining and building software solutions. It brings together business people (domain experts) and developers. Working as a one team, they define the model of the domain, and express it as a set of diagrams. The model is developed in such a way that developers can easily implement it, whilst the experts’ knowledge of the business gets translated into the working software.

This is a vastly oversimplified explanation of DDD, but this is all you can do in an elevator. If you get someone’s attention, show them this picture and give more details:

ddd mode

The experts and developers meet frequently and discuss the problem at hand. They explore the domain in what are known as knowledge-crunching sessions. They break up the domain into several sub-domains, each with its own model at its center. These sub-domains have boundaries and each one represents a different aspect of the business, a different context.

These sub-domains are also called Bounded Contexts because each model, consisting of entities, has its own language associated with it. Entities are bounded inside a context and the same entity will have a different meaning within the boundaries of a different context.

The language used to describe the model and its entities is called a ubiquitous language. Ubiquitous means everywhere, and it's called that, because it is used by all involved in the process of knowledge crunching: developers, business people, testers, and workers in the field, i.e. the language is used everywhere. However, each bounded context has its own, different ubiquitous language, similar to the fact that within the boundary of each country, we speak a unique language. Each model in each bounded context is explained with its own language, and each language has meaning only within the boundaries of its own bounded context.

Let’s look at an E-Commerce Domain. A customer entity will have a different meaning within different bounded contexts.

There are many techniques that help to distill the knowledge of the domain experts and translate it into the model, but they are beyond the scope of this article. Luckily, there are many resources out there and a helpful community of DDD practitioners. And remember, if you are developing software to solve a complex business problem, DDD is most likely right for you. If you don’t use the DDD, the developer's misunderstanding of the domain will probably get distilled into the code. If you do use DDD, the domain expert knowledge of the domain will translate into clean and maintainable code that meets the business needs.