The Domain Model

Learn about why you should use a Domain Model to create a shared understanding of your problem domain and what this Domain Model is.

Mattias Holmqvist

Learn about why you should use a Domain Model to create a shared understanding of your problem domain and what this Domain Model is.

Before starting to develop software there is an idea somewhere - a problem that should be solved. We turn to software as a useful tool to implement solutions to these problems but since it is rarely the case that the developers are the experts of the problem they are implementing a solution for, we need to communicate these ideas someway. This is where modeling enters the field.

Every software development task is initiated by some kind of modelling. There are different methods and tools that can be used to break down ideas and requirements into something that can be translated into a useful piece of software, but the goal is the same: to understand the problem enough to be able to build a solution correctly and efficiently.

What is the Domain Model?

The Domain Model is the artifact that we create during the phase of modeling. It will contain code, post-it notes, words, drawings and other artifacts. It is constantly in motion and is never a static set of information. It is our common understanding and interpretation of the problem at this point.

There are any number of Domain Models that solves a particular problem. The goal of the Domain Model is to provide a useful solution to the problem so that we can build good business around the software we create. The Model should never be a complete representation or description of the business or the problem statement, but rather a careful selection of the concepts that must be involved in order to solve the problem in a good way.

It is a difficult process to distill and develop a great Domain Model. It requires a great deal of collaboration, difficult discussions and a lot of coffee.

Where does the model apply?

In a larger system, there are typically many parts and sub-systems that are integrated. Eric Evans compared Bounded Contexts to cells, which "membranes define what is in and out and what can pass". In these larger systems we come up with different models, since there are different problems that must be solved. Each of these models are valid within their Bounded Context.

Domain-Driven Design is very different from something that we experienced in the old days of Enterprise modeling, where the whole company's processes and data should be modelled in a single artifact. What Evans did so beautifully in his book was to acknowledge that there are multiple models at play and he provided a language for they relate to each other. This is the topic of Strategic Design.

Who owns the Domain Model?

Your domain model is your joint understanding of the problem and how you intend to solve it. It is important that the team responsible for the Bounded Context where the model applies have ownership of the model, since they will be delivering the code to implement the model. Cross-functional teams and good collaboration with stakeholders are crucial to be efficient with modeling, and it's useful to have a number of modeling techniques to use depending on what stage you are in.

Modeling techniques

A lot of discussion and improvement has taken place during the last couple of years when it comes to concrete tools to apply the ideas in Domain-Driven Design.

  • User Story Mapping is a way to break down a larger idea into chunks while maintaining a consistent whole. It is a great tool to have to be better at working iteratively with larger ideas or products.

  • Event Storming was coined by Alberto Brandolini. It is a workshop/brainstorming technique for bringing developers, stakeholders and domain experts together to model the system using events.

  • Event Modeling has been made popular by Adam Dymitruk. Just like Event Storming it puts the notion of time and events in the center. It is a very succinct and elegant way of modeling complex software.