Index
- What is Domain-Driven Design?
- The role of specialised models
- Strategic DDD: domain subdivision
- Collaborative modelling
- What DDD is not
- Conclusion
As we explained in our article ‘Why do so many IT projects fail?’, software development is never an end in itself, but a tool to solve real problems. Technology, in this context, is the means to an end, not the end itself. To design effective software, it is essential to fully understand the problems one wants to solve.
At the heart of the matter is therefore technique: understanding the dynamics of the problem is essential in order to develop software that not only works, but meets the requirements precisely. After all, a software does not represent knowledge of the domain, but what the developers have understood about it. Good understanding of the domain therefore becomes the key to creating targeted, effective and efficient solutions.
Yet how can this understanding be structured to deal with the complexity of software? Domain-Driven Design provides a practical approach, which is divided into two main levels: strategic and tactical.
What is Domain-Driven Design?
Domain-Driven Design, often abbreviated to DDD, is an approach to software design introduced by Eric Evans in his 2004 book ‘Domain-Driven Design: Tackling Complexity in the Heart of Software’. The aim of DDD is to tackle the complexity of software by focusing on understanding the domain in which it operates.
Evans presents a set of concepts and tools to represent domains in software in a clear and shared way. The main idea is that successful development requires a deep and shared understanding among interdisciplinary team members such as developers, testers and domain experts.
Key points of DDD:
- Software must reflect the logic and structures of the domain.
- Communication between developers and domain experts is crucial.
- The creation of a shared language (Ubiquitous Language) helps to avoid ambiguities and misunderstandings.
DDD operates on two main levels:
- Strategic: focuses on the big picture, dividing the domain into well-defined areas to better manage complexity.
- Tactical: provides practical tools and patterns to translate domain understanding into code.
The role of specialised models
When creating software that solves specific problems, development teams must model the structures and rules of the domain. Those models take shape through diagrams, code and discussions. In DDD, the domain-oriented model is the core of the software system.
The importance of contexts
The larger a model becomes, the greater the inconsistencies. Many business concepts have different meanings depending on the context, and forcing everything into one model leads to confusion and rigidity. To solve this problem, the DDD introduces Bounded Contexts, which divide the domain into smaller, independent models.
For example, in a system for a cinema, a ‘ticket’ could be:
A saleable unit (with price, discount, VAT).
An access authorisation (with validity and conditions).
Instead of modelling everything in one ‘ticket’, separate models are created for each context. This approach reduces complexity, makes the software more modular and improves collaboration in teams.
Strategic DDD: domain subdivision
Subdomains
The first step in strategic planning is to divide the domain into subdomains, representing the different areas of the business. These are classified into:
- Core domains: crucial to the success of the business. They require special attention and internal development.
- Supporting subdomains: not central, but essential for the functioning of the core domains. They can be company-specific.
- Generic subdomains: standard processes, such as accounting, that do not provide a competitive advantage. Often outsourced to third-party software.
This subdivision makes it possible to identify areas on which to concentrate efforts, avoiding investing resources where not necessary.
Delimited contexts and shared language
Bounded contexts establish clear boundaries for each sub-domain. These boundaries are also linguistic: each context uses a specific language shared by team members. This Ubiquitous Language evolves over time through continuous dialogue between developers and domain experts.
Collaborative modelling
Collaborative modelling is a key practice of DDD. It consists of bringing together domain experts and technical teams to jointly develop models and define boundaries. Commonly used methods include:
Event Storming: A technique for mapping business processes and identifying key events.
Domain Storytelling: Telling stories to understand the flow of activities in the domain.
Example Mapping: Structuring concrete examples to clarify rules and requirements.
The workshops promote shared understanding and improve communication, which are key elements in building software that accurately reflects the domain.
What DDD is not
Some common misunderstandings should be clarified:
DDD is not a framework: It is not a library or a default tool.
It is not mandatory to implement it entirely: It can only be applied where it has the greatest impact.
It is not synonymous with microservices: Although it may favour modular architectures, it does not necessarily require microservices.
DDD does not eliminate complexity, but helps manage it through a deep understanding of the domain and a shared language.
Conclusion
Domain-Driven Design is an approach that puts domain understanding at the centre of addressing software complexity. Through specialised models, bounded contexts and shared languages, DDD helps interdisciplinary teams collaborate better and create more effective software.
It is not a rigid methodology, but a set of flexible principles that can be adapted to the needs of each project. Its true value lies in its ability to align people and concepts, building solutions that faithfully reflect real-world logic. With integrated use of the strategic and tactical levels, every aspect of development can be approached with greater clarity and precision.
.jpg)
