Domain-Driven Design

Something that frequently comes up when speaking about software development, architecture or something like that, that isn't about a specific framework or pattern, then it's for sure Domain-Driven Design (DDD). It's in general a very popular topic at conferences and there are a lot (and I mean A LOT) of articles and discussions about this topic. So why should I write about this?

I read and saw a lot of those DDD articles and talks, but often they are only targeting one specific part of DDD. For me, it feels like there are only very few articles and talks that give a general view of software development and where to put DDD in it or where DDD is in this general overview. So my motivation for this blog post is to put DDD in the general picture of software development instead of focusing on very specific topics.

The Problem

When we take a look at the act of creating software it always starts with some kind of problem. This problem is something we want to solve or it's something we want to achieve (then it's not really a problem but anyway ...). So there is some kind of vision like a tool or a product - not necessarily with the goal of making money, but something that improves our lives. In most cases, this vision is not technical in the true sense but it's something that we want to solve in a technical way. Furthermore, our vision or the problem we want to solve is something that occurs in our lives - in our real world.

This means, that we as software developers somehow need to transfer that vision/problem into something technical so that we are able to solve it in a technical way. So what this is means is that we always need to create some kind of model that abstracts the real problem into something that can be handled technically. This is fundamental for software development and it seems like this is something so simple that we often don't realize we are doing this. It doesn't even matter how big or small the problem is, but as soon as we are going to build software we are going to create a model. Some terms that are often used (for example in DDD) are problem space and solution space, where the problem/vision is part of the problem space and our created model is part of the solution space.

The Solution

There are many ways to get to a solution and I'm not talking about programming languages, frameworks, or ways of implementing something. I'm still talking about the model ... Like in the real world where different people have different perspectives on things, it's also possible to have or create different models for the same problem/vision. In my opinion, this is the main point of DDD.

Software developers are by nature very technical persons and often we aren't experts in the areas we are creating software for. We are no doctors even if we create software for medical purposes, we are often no big businessmen even if we create software for e-commerce, and so on. This is often a problem on its own because this means that we often aren't really good at creating models that match reality really well. Our models are often very technical abstractions that are mostly based on data describing visible attributes and methods that describe what happens with that data.

It's possible to create good software using those kinds of models but when it comes to complex software that is developed by larger teams a good model becomes very important and makes a big difference in maintainability and overall costs.

Creating a Good Model

Domain-driven design helps you to create a good model and, therefore, helps you to create good maintainable software. This is also the reason why there is some kind of hype around DDD. There are just two things in DDD that make the big difference here: ubiquitous language and bounded contexts.

The Ubiquitous Language

The main point of DDD is that you are forcing your model to match the domain of the problem space. This means that you don't abstract terms of a specific domain and rephrase them, instead, you dig deep into that domain trying to understand it and then use this knowledge and make it part of your model.

In general, this is done by talking with the domain experts and creating a model together with them. This forces software developers to adapt the terminology, learn the processes, and overcome the usage of technical terms so that the domain experts can understand the software without being a developer themself. DDD is labelling this as the ubiquitous language, which is the result of doing exactly this.

The Bounded Contexts

The other important part of DDD is the bounded context. These bounded contexts are defined within the model and help to structure it (and therefore the software). Specific parts of the model that are highly coherent (and therefore coupled) make up a bound context or - another often used word in DDD - a domain. These contexts or domains are then set into specific relationships with each other. Another thing that is often done is categorising these domains into three groups: core, support, and generic. This is done the specify the importance of these domains regarding the business. So it's more important for the management than for the developers, in my opinion.

Lessons Learned

Domain-driven design helps software developers create a model that is not only understood by developers, but also by other people familiar with the subject of the software. To achieve this, it values strong communication and ubiquitous language as well as a highly structured model. Overall this should lead to good software.

Software Development DDD