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 our 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.
This process is composed of 8 steps which are introduced below:
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.
As a starting point, we recommend The Business Model Canvas for the business perpective, User Story Mapping for the user vantage point.
- Impact Mapping
- The Business Model Canvas
- The Product Strategy Canvas
- Wardley Mapping
- User Story Mapping
- People who design, build, test software
- People who have domain knowledge
- People who understand the product and business strategy
- Real end users, not only their representatives in your organisation
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.
- People who design, build, test software
- People who have domain knowledge
- People who understand product and business strategy
- People who understand the customers' needs and problems
- Real end users
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:
- reduced cognitive load, so that we can reason about parts of the domain independently,
- give development teams autonomy, so that they can work on separate parts of the solution,
- identifying loose-coupling and high-cohesion in the domain which carries over to our software architecture and team structure.
As a starting point, we recommend carving up your event storm into sub-domains and Context Maps.
Credit: Alberto Brandolini
- Business Capability Modelling
- Design Heuristics
- EventStorming with sub-domains
- Independent Service Heuristics
- Visualising Sociotechnical Architecture with Context Maps
- People who design, build, test software
- People who have domain knowledge
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.
- Business Process Model and Notation
- Domain Message Flow Modelling
- Process Modelling EventStorming
- Sequence Diagrams
- People who design, build, test software
- People who have domain knowledge
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.
- Core Domain Charts
- Purpose Alignment Model
- Wardley Mapping
- Revisiting the Basics of Domain-Driven Design
- People who understand product and business strategy
- People who design, build, test software
- People who have domain knowledge
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.
As a starting point, we recommend visualising sociotechnical architecture with the Context Maps. A brief overview of the most important patterns can be found under the context-mapping GitHub Project.
Credit: Michael Plöd
- Dynamic Reteaming
- Pioneers, Settlers & Town Planners
- Team Topologies
- Visualising Sociotechnical Architecture with Context Maps
- People who design, build, test software
- People who have domain knowledge
- People who understand the product and business strategy
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.
- People who design, build, test software
- People who have domain knowledge
- People who are responsible for the product
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.
- Aggregate Design Canvas
- C4 Component Diagrams
- Design-Level EventStorming
- Event Modelling
- Hexagonal Architecture
- Mob Programming
- Model Exploration Whirlpool
- Onion Architecture
- Unified Modelling Language
- People who design, build, test software
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.
