Skip to main content

Short intro to Domain-Driven Design

You may have heard of DDD and, yet again, you may not have. Let us give you a short introduction so that we all know what it is and future articles may build on this knowledge.

DDD (Domain-Driven Design) is a different way of thinking about your software; in fact it is probably the right way to think about it.

As the name implies, its focus is on the domain, i.e. the concepts behind the business itself, rather than on the technology. It remembers us that, when we’re coding, our main target should be solving the business problems, either by making existing procedures easier or faster, or by granting users with new features and new possibilities.

Eric Evans summarizes DDD like this:

  • focus on the core complexities and opportunities in the domain
  • explore models in a collaboration of domain experts and software experts
  • write software that expresses those models explicitly
  • speak a ubiquitous langage within a bounded context

Each of these topics is really important and would require an in-depth explanation, but – since we promised you a short intro – let’s just reword them from our point of view.

1) Each business contains complex workflows and rules. This is ok. That complexity is an opportunity for us to provide value; software development should be all about providing value. We should be ready to change and adapt our code to new needs. When the code is frequently refactored and generally looked after, this comes easier.

2) If we want for your software to fit within the domain and efficiently solve business problems, we have to work alongside domain experts, i.e. people who actually do the job and know exactly how it should work. Good results can only be obtained by bringing together business knowledge and technology expertise.

3) Our software should adapt itself to the business workflow, not the other way around. People should not learn a different way to do things than the one they are using already. They should get a simpler, faster yet intuitive way to complete the same workflow. This should be the one and only target of all our thinking and coding as developers.

4) Naming in code has always been important, but if we follow DDD principles that is even more important. All entities and processes have a very specific meaning within the business, and even more important, they may have a different meaning within different parts of the business (contexts). We should respect and highlight this meaning by using appropriate names for any piece of code.