Domain-Driven Design (DDD) is a method for developing a team's understanding of a problem space. It emphasises placing the primary focus of a project on the core area of the business - the core domain. This often takes the form of facilitated workshops with domain experts that culminates in the creation of a Domain Model that represents a shared understanding of the domain.
A Domain Model is a conceptual model, often represented as an entity-relationship diagram, produced during the Domain-Driven Design process. By describing core business concepts and their relationships to one another, a Domain Model can be the preeminent tool informing strategic data and technology decisions.
Domain-Driven Design leads to:
When developing products with complex domains, a team's ability to learn is the most significant constraint. It also presents the largest risk, as ambiguity or lack of domain knowledge compound errors in the system. These types of errors can be expensive to fix if caught late.
By refocusing the project on its primary domain, design decisions can be made which are informed by a shared team understanding.
Domain-driven design (DDD) is an important approach to software development that focuses on the specific domain that the software is modelling. The Data Language team has been using DDD approaches since Eric Evans introduced the idea in 2003. Creating a "Domain Model" is part of our core MO, and the DDD process and outcomes hugely benefit all parts of any business.
We believe that DDD is an essential approach to software development. We have seen firsthand the benefits of DDD, and it helps improve the quality, maintainability, and performance of software, as well as driving the shared understanding of information architecture across a business.
Skilled facilitation of domain modelling sessions helps our clients get to grips with their domain. Through collaborative domain modelling exercises, we work with stakeholders to gain a broad understanding of the target domain. We typically focus on the high value elements of the domain, iteratively refining and validating models to achieve the right level of detail to deliver the most business value.
Another application of DDD is in projects that require strong information architecture. Where the intention is to organise a product around the entities and relationships of the domain. This is often seen in approaches that build on taxonomies or knowledge graphs.
The domain model, which is one output of Domain Driven Design, is a conceptual model. It will often be represented as an entity relationship diagram, and it forms a map describing core business concepts and their relationships to inform all strategic data and technology decisions.
Domain modelling sessions will most likely take place in front of a whiteboard where the team and subject matter experts will draw back at each other using illustrative examples from the problem space. Through this exploration of the domain team members reach a consensus in their understanding. This consensus (or ubiquitous language) is the foundation that development work can then build on. In a complex domain you will need to conduct many sessions to capture different perspectives and establish how meaning changes between contexts and edge cases.
It is important to note that domain-driven design puts less emphasis on the documentation (including the domain model) but rather puts more emphasis on the collective learning that the team gains from the process, so businesses must be careful to emphasize the human interaction elements.
This helps reduce the risk of expensive mistakes being made late-on in a project where they have become encoded in lines of code or data models.
For products that deal with complex domains, the team's collective ability to learn becomes the most significant constraint. It also presents the largest risk as ambiguity or lack of domain knowledge compound errors in the system. These types of errors tend to be expensive to fix if caught late. By refocusing the project on its primary domain design decisions can be made which are informed by a shared team understanding.
Domain models are supposed to grow and change as the problem space evolves. We often start an engagement with a big picture view of an organisation's domain. This helps everyone understand the process and its potential value, as well as setting more focused sessions in context. As a product moves into a discovery phase, a key part of discovery becomes understanding the domain and developing the ubiquitous language of the team. It is key here that we attempt to keep the models as small and loosely coupled as possible. In DDD we will talk about bounded context and avoiding designing all encompassing enterprise data models. Enterprise scale data models tend to work against the goals of making the domain easy to communicate to others and retaining model flexibility over time.
.svg?auto=format&fit=crop&w=600&dpr=3&q=35)
