What is the Domain Model in Domain Driven Design?
To understand Domain Driven Design, you really need to understand the terminology. However, I often find that terminology in the absence of real world context is not only difficult to understand, but almost impossible to apply and reap the benefits of.
Domain Model is a term you will hear a lot in Domain Driven Design. I think Domain Model is one of the most obvious examples of terminology that means absolutely nothing unless you understand the context in which it applies.
In today’s article we’re going to be looking at what Domain Model actually means, why it is important and how to use it within the context of your development projects.
The Domain is the problem
Domain Driven Design is predicated around the idea of solving the problems organisations face through code. This is achieved by focusing the investment of resources into the heart of the business logic of the application.
The domain therefore is, the world of the business. Whenever you hear the phrase “Domain Driven Design”, you should think of it as “Business Problem Driven Design”.
The domain is the world of the business you are working with and the problems they want to solve. This will typically involve rules, processes and existing systems that need to be integrated as part of your solution.
The domain is the ideas, knowledge and data of the problem you are trying to solve. Most businesses will have terms that have specific meaning within the context of their organisation. They will also likely have metrics, goals and objectives that are unique to their business.
All of the knowledge around the company and how it operates will form the domain of your Domain Driven Designed project.
The Model is your solution
The Model of an Domain Driven Designed project is your solution to the problem.
The Model usually represents an aspect of reality or something of interest. The Model is also often a simplification of the bigger picture and so the important aspects of the solution are concentrated on whilst everything else is ignored.
This means your Model should be focused knowledge around a specific problem that is simplified and structured to provide a solution.
The Domain Model
So if the Domain is the world of the business, and the Model is your solution, what is the Domain Model?
The Domain Model is your organised and structured knowledge of the problem. The Domain Model should represent the vocabulary and key concepts of the problem domain and it should identify the relationships among all of the entities within the scope of the domain.
The Domain Model itself could be a diagram, code examples or even written documentation of the problem. The important thing is, the Domain Model should be accessible and understandable by everyone who is involved with the project.
The Domain Model should also define the vocabulary around the project and should act as a communication tool for everyone involved. The Ubiquitous Language is an extremely important concept in Domain Driven Design and so it should be directly derived from the Domain Model.
One of the downfalls of many software development projects is the misunderstanding of terms, objectives and proposed solutions that are scoped at the beginning of development.
The Domain Model should act as a clear depiction of the problem that is being solved and the proposed solution. It is extremely important that all stakeholders of the project contribute to the Domain Model so that everyone understands the key concepts and definitions of the vocabulary of the project and how the problem is being tackled and solved.
Why is the Domain Model important?
So the Domain is the world of the business, the Model is your solution and the Domain Model is the structured knowledge of the problem.
Why is this important to Domain Driven Design? Well, I think there are three reasons why a Domain Model is important.
The Domain Model and the heart of the design shape each other
The code that you write should be intimately linked to the model of the problem you are solving. Anyone on the team should be able to look at your code and understand how it applies to the problem you are solving.
When developers deviate from the model, they write code that is built around their mental model of the problem. The code that you write should be directly derived from the agreed Domain Model to ensure that your solution meets the requirements of the business.
The Domain Model is the backbone of the language used by all team members
Every single person on the project team should use the Ubiquitous Language. This means that technical and non-technical people have a common language to communicate so there is no loss of understanding between parties.
The Ubiquitous Language should be directly derived from the Domain Model and so without a Domain Model you don’t have a Ubiquitous Language.
Without a Ubiquitous Language you will start to feel the friction of communication and the loss of understanding between technical and non-technical members of the team. If the code that is written starts to deviate away from the requirements of the business experts, the end solution won’t satisfy the goals of the project.
The Domain Model is distilled knowledge
The Domain Model should be the outcome of an iterative discovering process where everyone on the team meets to discuss the problem you are facing and how it should be solved.
This early collaboration between domain experts and the development team is critical to the success of the project.
The Domain Model should capture how you think about the project and all of the distilled knowledge that has been derived from those collaboration sessions.
Whenever a decision needs to be made during the course of the project everyone should refer to the Domain Model to look for the answer or to try to iteratively evolve the design to discover a hidden truth that has not previously been exposed.
How do you arrive at a Domain Model?
Arriving at a Domain Model is an iterative approach that attempts to discover the real problem that is faced and the correct solution that is required.
It’s important to focus a Domain Model on one important problem. Trying to capture the entire scope of a business inside of a single Domain Model will be far too overcomplicated and most likely contradictive as concepts and ideas move around the organisation.
The problem should be mapped out through talking to business experts to discover the problems they face. This should form the conceptual problem that you are looking to tackle.
Business experts won’t talk in the terms of technical solutions, and so it is your job to correctly interpret their problems into technical solutions.
During this process the important aspects of the problem should be picked out from the language and given concrete definitions to form the Ubiquitous Language.
It doesn’t really matter whether the Domain Model is created in code, as a diagram or in prose. However there should be a tight feedback loop where everyone on the project discusses the proposed Domain Model to get closer to the solution. This is an iterative approach that will likely encompass code, diagrams and prose to really understand the problem and to discover the correct solution.
What is an example of a Domain Model?
It’s difficult to show an example of a Domain Model as it should really be taken from a real world business problem.
However, for the benefit of this article, lets pretend we have the following business problem we need to solve:
- A business wants to create software to manage it’s projects
- Projects are derived from a product roadmap
- The project is picked due to certain criteria
- The project is assigned to a project manager
- The project manager organises the team
- The sprint is planned
The 6 steps that I’ve outlined above is the manually process that managers at a fictitious organisation walk through to assign tasks to employees. This is the Domain because it is solely focused on the world of the business.
The Model is focused on this one aspect of project management within the scope of the bigger organisation. In large organisations there are probably numerous ways that work is chosen and allocated to teams of employees. However in order to stay on track, we only care about this one, structured problem.
The Domain Model should take the Domain and the Model to form a a conceptual solution to the problem.
For example, we can see that we will probably need entities for Roadmap, Project Managers, Employees, Team and Sprint.
We will need a way of selecting projects from some kind of persistence storage.
We will need a way of capturing the business logic of Criteria to make decisions of priority based upon what is important to the business.
And finally we will need a way of planning a sprint and allocating times and resources to ensure that the work is completed.
I’m sure if this was a real world problem we would need to explore the concept of assigning projects in much greater detail, but hopefully you see what I’m getting at.
Conclusion
The Domain Model is the important starting point when taking on a Domain Driven Design project. Domain Driven Design is all about solving the problems of an organisation, and so the Domain Model is all about understanding and interpreting the important aspects of a given problem.
The Domain Model represents the Ubiquitous Language of the project, the important concepts and the relationships between those concepts.
The Domain Model should also be used as a way to validate as to whether everyone on the team understands the problem. A Domain Model will focus attention on a specific problem and it will define the vocabulary and the context of the important things that need to be considered.
Arriving at a solid Domain Model for a given problem is an iterative approach of collaboration between the business experts and the technical team. It should act as a source of truth for the project and it is a living document as the project progresses.
Comments
Post a Comment