Domain-Driven Design
What is Domain-Driven Design?
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 and the development of a shared set of conceptual models. DDD has the additional benefit of creating a shared understanding (ubiquitous language) between teams when designing technical solutions.
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.
Would my project benefit from Domain-Driven design?
Common reasons that you would look to Domain Driven development would be projects that need to distill the knowledge of domain experts into a product. These types of projects can often suffer from a disconnect in domain understanding. Discovering this disconnect in code or in data models is expensive to fix. DDD can address this by tackling differences in domain understanding before implementation begins. It can create a perfect bridge of understanding between the business stakeholders, the problem-space, and the technical teams.
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.
We see Domain-Driven Design as a critical starting point for all our knowledge graph implementations, and on the majority of our project engagements, including development of our own products.
Our Products
Frequently Asked Questions
A domain model is a conceptual model which results from the activity of domain-driven design. The conceptual model will often be represented as an entity relationship diagram. It is important to note that domain-driven design puts less emphasis on the documentation but rather on the collective learning that the team gains from the process. 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.
Domain-driven design is the process of optimising a team's ability to learn about the domain it is working in. Documents are often places where we can hide our ignorance about a domain and DDD discourages the over reliance on documentation. 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.
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.
The outcome of domain modelling is a set of related conceptual models and a ubiquitous language. A domain model is one of potentially many models that describe your organisation's core business space. If a project team designs, writes code or acts on a strategy with a shared understanding of the domain, it reduces project risk and can improve the quality of the software being developed.
