This process gives you a step-by-step guide for learning and practically applying each aspect of Domain-Driven Design (DDD) - from orienting around an organisation’s business model to coding a domain model.
Using this process will guide you through each of the essential steps in designing a software system with the DDD mindset, so you can focus on your business challenges and not be overwhelmed by learning DDD at the same time.
Once you have been through a few iterations of the process you will have the foundational DDD theory and practical experience to go deeper into DDD. Then you will be able to adapt and improve the process to suit your needs in any context. On a real project you’ll often be jumping back and forth between these steps.
This process is for beginners. It is not a linear sequence of steps that you should standardise as a best practice. Domain-Driven Design is an evolutionary design process which necessitates continuous iteration on all aspects of knowledge and design.
If you’re new to DDD or just not sure where to start, this process can reduce your cognitive load. It will guide you through following scenarios, and possibly others:
At the start of a new project the number of things you need to think about can be overwhelming. One or two iterations of this process can help you put the foundations in place.
Before getting to work on modernising your legacy system, a few iterations of this process can help you to uncover essential information needed to create a vision for your target architecture.
When starting a new initiative involves a significant investment across many teams, it is essential to cover the 8 steps in the process. This process can guide you through the first few iterations.
Software development is a learning process. You can apply the DDD Starter Modelling Process at any time to uncover new insights, identify new opportunities, or simply share knowledge around the team.
This process can be the foundation for assessing how well your current system is aligned to the domain and business model.
A loosely-coupled architecture enables teams to work in parallel without being blocked. A loosely-coupled architecture also must be aligned to coupling in the domain. This process will help you to design a software architecture, and a team structure aligned with your domain.
This process is ideal when you are new to DDD and want to practice, or you want to teach others the different aspects of modelling a domain. It’s important to communicate that this linear process is not a realistic process. It’s just a starting point to reduce cognitive load until you are confident with DDD.
This process can be customised in many ways. On a real project, you’ll be switching between all 8 steps based on the new insights you gain or need to gain.
Below are a few reasons for deciding when to change the order or switch between steps.
If you want to get your whole team collaborating immediately, modelling the domain which they are familiar with might be more comfortable than talking about business models and strategy which they are less comfortable with.
Before looking forward to the business vision and going deep into the domain, it might be better to visualise the existing architecture first. Start with step 5 and map out your strategic portfolio to see what the major constraints you will face are.
On some projects it makes sense to start by writing code sooner. Perhaps you need to deliver an MVP or the domain is so complex that creating a model in code is necessary before you can consider the architecture.
Before you dive into the definition of individual bounded contexts, it may be beneficial to model the domain multiple times and look for different ways to decompose your system into sub-domains and teams.
For a great deal of projects there are organisational constraints that we need to take into account. If this is the case, you should consider identifying possible team structures before designing architectures that you will never be able to implement.
Steps 7 (Define) and 8 (Code) can occur concurrently. This may happen when you are coding a bounded context, and the insights you get from writing code make you change the high-level design.
The modelling process is composed of 8 steps which are introduced below.
A good talk that gives an overview of the process in the context of typical phases of designing sociotechnical architectures is “Sociotechnical Architecture: co-designing technical & organizational architecture to maximize impact” by Eduardo da Silva. Eduardo groups the activities of the process and its 8 steps in four distinct phases, namely:
Align our focus with the organisation’s business model, the needs of its users, and its short, medium, and long-term goals.
Every decision we take regarding the architecture, the code, or the organisation has business and user consequences. In order to design, build, and evolve software systems most effectively, our decisions need to create the optimal business impact, which can only be achieved if we are aligned to the business goals, as well as supporting the users current and potensial future needs.
Badly designed architecture and/or boundaries can have a negative impact or even make it impossible to achieve these goals.
Discover the domain visually and collaboratively.
This is the most crucial aspect of DDD. You cannot skip discovery. If your whole team doesn’t build up a good understanding of the domain all software decisions will be misguided.
Spreading domain knowledge through the whole team will create a shared understanding. It enables the developers to build a software system aligned to the domain which can be more flexible to incorporate future business changes.
Ensuring that domain knowledge is spread across the whole team enables its members to contribute with ideas for improving the product.
Teams who are successful with DDD are practicing discovery techniques on a frequent basis. There is always more to learn about the domain.
When first attempting discovery, a facilitator who is experienced with techniques like EventStorming can help a team to see the true benefits of discovery beyond a superficial level.
We strongly encourage you to check out Visual Collaboration Tools.
As a starting point, we recommend EventStorming.
Decompose the domain into sub-domains - loosely-coupled parts of the domain.
We decompose a large problem domain into sub-domains for a few key reasons:
As a starting point, we recommend carving up your event storm into sub-domains and Context Maps.
Connect the sub-domains into a loosely-coupled architecture which fulfills end-to-end business use-cases.
It is imperative to not only decompose a large domain into parts but to also carefully design the interactions between those parts to minimise unwanted coupling and complexity. It is necessary to challenge the initial design by applying concrete use-cases to uncover hidden complexity.
As a starting point, we recommend Domain Message Flow Modelling.
Strategically map out your sub-domains to identify core domains: the parts of the domain which have the greatest potential for business differentiation or strategic significance.
Time and resources are limited, so understanding which parts of the domain to focus on is critical to delivering optimal business impact.
By analysing what your core domains are, you will have a better idea of how much quality and rigour to each part of your system, and you’ll be able to make highly-educated build vs buy vs outsource decisions.
As a starting point, we recommend Core Domain Charts.
Organise autonomous teams that are optimised for fast flow and aligned with context boundaries.
Teams need to be organised to have autonomy, clear goals and sense of purpose. In order to do that we need to take into account organisational constraints, so that teams organise themselves for fast flow.
Organisation is not something that is done to teams, rather teams should be involved in the process of defining their boundaries, interactions, and responsibilities.
Some companies like Red Gate Software empower and trust their teams to fully organise themselves.
We can optimise how people collaborate with each other if we align teams with context boundaries. In order to right-size the teams we need to take into account available talent, cognitive load, communication overhead, and bus factor.
Define the roles and responsibilities of each bounded context.
Before committing to a design, make explicit decisions about the choices which can have a significant impact on the overall design. Have these conversations early while it is still easy to change your mind and explore alternative models.
Design collaboratively and visually and start to consider the technical limitations so that you can uncover constraints or opportunities.
As a starting point, we recommend the Bounded Context Canvas.
Code the domain model.
Aligning the code to the domain makes it easier to change the code when the domain changes. By collaboratively modelling the problem space with experts, the developers have a chance to learn about the domain and minimise misunderstandings.
As a starting point, we recommend the Aggregate Design Canvas.
Thanks to all existing and future contributors and to the following individuals who have all contributed to the DDD Starter Modelling Process:
The Domain-Driven Design Starter Modelling Process is freely available for you to use. In addition, your feedback and ideas are welcome to improve the technique or to create alternative versions.
If you have questions you can ping us or open an Issue.
Feel free to also send us a pull request with your examples or experience reports.
This work is licensed under a Creative Commons Attribution 4.0 International License.