Domain Driven Design: Connecting Software and Business Domains

Writing software involves software architects and programmers. They understand software concepts, tools and implementation details. But they may be disconnected from the business and hence have an incomplete understanding of the problem they’re trying to solve. Domain-Driven Design (DDD) is an approach towards a shared understanding within the context of the domain.

Large software projects are complex. DDD manages this complexity by decomposing the domain into smaller subdomains. Then it establishes a consistent language within each subdomain so that everyone understands the problem (and the solution) without ambiguity.

DDD is object-oriented design done right. Among its many benefits are better communication, common understanding, flexible design, improved patterns, meeting deadlines, and minimizing technical debt. However, DDD requires domain experts, additional effort and hence best applied for complex applications.

Domain can be defined as “a sphere of knowledge, influence or activity.” For example, Accountancy is a domain. An accountant is someone who knows this domain well. She is considered a domain expert. She’s perhaps not a programmer and therefore can’t build an accounting software. But she can advise developers on the intricacies and workings of the domain.

Consider the domain of air traffic. A developer might imagine that pilots decide on the route (a sequence of 3D points) to a destination. A domain expert might clarify that routes are pre-determined and each route is actually a ground projection of the air path.

To better manage complexity, a domain can be broken down into subdomains. In the e-commerce domain, Payment, Offer, Customer and Shipping are possible subdomains.

Domain is the business or problem to be solved. Model is the solution. Likewise, subdomains in the problem space are mapped to bounded contexts in the solution space.

Domain can be defined as “a sphere of knowledge, influence or activity.”

Consider the terms Member and Payment used in a country club. For some stakeholders the terms relate to club membership fees; for others, they’re about tennis court booking fees. This disconnect is an indication that the domain is not really one and indivisible. There are subdomains hiding in there and they’re best modelled separately. Bounded contexts are the solution.

When a model is proposed for a subdomain, it’s applied only within the boundaries of the subdomain. These boundaries in the solution space define a bounded context. When teams understand the bounded contexts, it becomes clear what parts of the system have to consistent (within a bounded context) and what parts can develop independently (across bounded contexts). Bounded contexts therefore imply a clear separation of concerns.

Without bounded contexts, we’ll end up with a single large complex model of many entities and relationships. Entities will get tightly coupled. The end result is often called a Big Ball of Mud.

Bounded contexts may overlap or may be neatly partitioned. Bounded contexts often relate to one another and this is captured in a context map.

Consider the terms Member and Payment used in a country club. For some stakeholders the terms relate to club membership fees; for others, they’re about tennis court booking fees. This disconnect is an indication that the domain is not really one and indivisible. There are subdomains hiding in there and they’re best modelled separately. Bounded contexts are the solution.

UL must be consistent and unambiguous. It should evolve as understanding of the domain changes. A change in language implies a change to the model. In fact, the model is not just a design artifact used just to draw UML diagrams. Model is the backbone of the language. Within a bounded context, use the same language in diagrams, writing, speech and code.

To create an UL, have an open discussion, analyze existing documents, express the domain clearly, and define an agreed glossary. Glossary alone won’t help. Use it consciously to arrive at a common understanding of the model.

• Entity: An object that has attributes but primarily defined by an identity.
• Value Object: An object with attributes but no identity.
• Aggregate: A cluster of objects treated as a single unit. External references are restricted to only one member, called the Aggregate Root. A set of consistency rules applies within the aggregate’s boundaries.
• Factory: A mechanism to encapsulate and abstract away the details of creating a complex object. A factory ensures aggregates are initialized to a consistent state.
• Repository: A mechanism to encapsulate storage, search and retrieval from a collection of objects. Its implementation is not a domain concern.
• Service: A stateless functionality that renders its service via an interface, typically used when a workflow doesn’t fit the current model.

Learn more about DDD through Eric Evan’s book: “Domain-Driven Design: Tackling Complexity in the Heart of Software,” or through the following links: Kiến Trúc DDD, Developia.org

Citation: Devopedia. 2020. “Domain-Driven Design.” Version 6, February 8. Accessed 2022-06-15. https://devopedia.org/domain-driven-design