Domain Driven Design¶

Domain-Driven Design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model. It emphasizes collaboration between technical and domain experts to solve complex problems effectively.

What is Domain ?¶

A domain is the problem space that should be solved by designing a software. A domain is often a complex collection of variables in a set environment that can shrink, expand and evolve.
For complex environments you can’t sit down and write code without understanding the essence of it.

What is Model ?¶

A model is, simply put, a representation or abstraction of the target domain. In order to map a domain in an easy and understandable man

Anemic Model¶

An anemic domain model is characterized by containing only less or no business logic.The business logic itself is mainly part of the service, which is working on top of the domain model.

The domain model therefore looks very clean. Just slightly different from the DTO classes.

Rich Model¶

The rich domain model is characterized by combining data and behavior and only keeping a thin service above.

Instead of being only a holder of data, regardless of whether valid or not, the domain model is responsible for representation of the use-cases and care about the requirements for valid internal state. It should not be possible to create an object with an invalid state. So I need to add the parts, which are done by the service in the anemic domain model example, related to validation of input, to the initialization part of the domain model.

Ubiquitous Language¶

Ubiquitous Language is a foundational concept in DDD. It refers to a shared language between developers and domain experts that is used consistently throughout the project. This language ensures that everyone involved in the project (developers, business stakeholders, testers, etc.) has a common understanding of the domain, its processes, and its rules. The goal is to eliminate misunderstandings and ambiguities that often arise when technical and non-technical teams collaborate.

Domain Storytelling¶

Domain Storytelling is a knowledge crunching technique. It brings together domain experts and development teams. The domain experts can see immediately whether you understand their story correctly.

Distilling the Problem Space of DDD¶

The figure above is a blueprint replica of how Scott Millett and Nick Tune illustrates the problem space of DDD

The blueprint starts with understanding the problem domain and business wish. From there, the domain experts and the development team sit together and understand the language of the domain — the ubiquitous language. Once the language is set and everyone are on the same level, they crunch through the domain knowledge. At this point, the development team should be ready to implement the distilled domain knowledge into code. They separate the code into appropriate sub domains with appropriate models. Hopefully, the development team has understood the domain vision as the domain experts envisioned it. Focusing on the core domain is critical as this is the main reason for the system being built.

Bounded Context and Sub Domains¶

A bounded context defines the limits of applicability for a ubiquitous language. Since domains often can become very complex and big, it is a good approach to distill the domain into smaller and separate models. So instead of having one big model for the domain, you have many smaller ones that are properly defined and has specific boundaries of what they are to encapsulate. Many larger domains will have multiple bounded contexts within them.

A large problem domain can be decomposed into sub domains to manage complexity and separate important parts from the rest of the system.

There are three kinds of sub domains that we here differentiate based on how much competitive advantage it yields:

Core Domain¶

The most important part of the system, the reason for the success. This will give you competitive advantage, so focus on this and make this as good as possible.

Generic Domain¶

This is not the core, but the core depends on it. e.g. email sending service, monitoring service and such. Try to re-use existing parts and don’t spend too much time on these systems.

Supporting Domain¶

Extra domains that help to support the core but does not provide any competitive advantage. Not recommended to invest heavily on but still needed in order to succeed in the core domain. Maybe even outsourcing could be a possibility here?

Distilling the Solution Space of DDD¶

The solution space covers patterns that can shape the architecture of your applications and make it easier to manage. DDD is architecturally agnostic in that there is no single architectural style you must follow to implement it.

Context Mapping¶

Context mapping is a strategic tool used to define and manage the relationships between bounded contexts. A bounded context is a conceptual boundary within which a particular domain model is defined and applicable. Since large systems often consist of multiple bounded contexts, context mapping provides a way to integrate and coordinate these contexts, ensuring they can communicate effectively without compromising their individual integrity.

How Are the Two Parts of DDD Connected?¶

Through ubiquitous language — the binding between the code and the analysis model.

When to use DDD ?¶

When are you supposed to leverage the power of Domain Driven Design?

DDD is suitable for complex domains and large-scale applications rather than simple CRUD applications. It focuses on the core domain logic rather than the infrastructure details. This approach helps build a flexible, modular and maintainable code base.

Reference¶

• "Domain Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans
• "Domain Driven Design Reference: Definitions and Pattern Summaries" by Eric Evans
• "Domain Driven Design Quickly" by Abel Avram and with Floyd Marinescu
• "Patterns, Principles, and Practices of Domain-Driven Design" by Scott Millett and Nick Tune
• "Domain Storytelling" by Stefan Hofer