Domain-Driven Design (DDD) is a concept introduced by Eric Evans in 2004 in his book: "Domain-Driven Design: Tackling Complexity in the Heart of Software". It aims to centre the development based on the domain system, which represents the business rules.
Software systems can be divided into subdomains, each with its own functional purpose. This approach applies the 'Divide and Conquer' paradigm to tackle complexity and identify the most critical parts of the domain that can be treated independently.
DDD is a design strategy that follows several principles and patterns to facilitate the process of building software systems focused on the pure domain.
Let's take a look at some of the most relevant DDD principles:
BOUNDED CONTEXT
It's an isolated area of responsibility in the domain that defines a strong boundary to separate other parts of the system. It determines the context in which a particular model is strictly applied without interacting with different contexts.
UBIQUITOUS LANGUAGE
It is the common language used by developers, domain experts, and everyone involved in the development lifecycle to communicate ideas about the domain system. It is the intrinsic vocabulary that is directly reflected in the development design.
"It is critical that developers use the business language in code consciously and as a disciplined rule. Doing so reduces the disconnect between business vocabulary and technological jargon." Best Practice - An Introduction To Domain-Driven Design | Microsoft Learn
Each bounded context has its own ubiquitous language regarding discussions, models and vocabulary. This principle is fundamental to prevent ambiguous, inconsistent terms from being used to specify business requirements and removes the error-prone vocabulary translation.
SEPARATION OF CONCERNS
It plays an important role in creating a well-defined structural design by dividing the whole domain into subdomains. This concept adheres to the Single Responsibility Principle (SRP) that applies to functions, classes and modules.
Now, take a closer look at some of the key elements of DDD:
ENTITY
It's a mutable class that contains business rules and has a unique identity within the domain model. An entity's uniqueness is determined by its unique identifier, usually called "Id" or "EntityId".
DDD entities are focused on behaviours rather than attributes. In contrast, anaemic models often have entities with little or no behaviour, and all of the domain logic is delegated to external services. The goal of DDD entities is to create a rich domain model based on these behavioural procedures.
VALUE-OBJECT
It's an immutable class that is defined solely by its attribute values. A value-object identity depends on the combination of its values, so two value objects with the same values are considered identical. As immutable objects, they are side-effect-free because they don't alter the object's state.
AGGREGATE ROOT
It's a cluster of related entities and value objects treated as a single unit. It's the entry point for external objects to interact with. "They guarantee domain consistency by ensuring that all the invariants (business rules) within the aggregate are ensured before any external interaction occurs." The Ultimate Guide to Domain-Driven Design | AppMaster
DOMAIN SERVICE
It's business logic that is not naturally attached to any specific entity or value object. It belongs in the domain layer and encapsulates actions in a stateless manner.
REPOSITORY
It's an abstraction layer that provides communication between the data persistence implementation and the aggregate roots to access and persist the domain data. It's an important DDD concept because the domain model should be persistent-ignorant.
DOMAIN EVENT
It captures an occurrence within the domain. The interested part(s) of the system will react accordingly to the triggered event.
DDD is not a plain methodology or a set of rules that dictate how to build code. It's an approach that includes various techniques, patterns and principles that can be applied to complex software systems.
What are the benefits of using DDD:
Improved communication: Technical and non-technical members speak the same language - no ambiguity to express the system's intent.
Unified vision: The software design is aligned with the domain problem, which ensures that the development process meets the actual needs of the business rules.
Modularity: The division of the whole system into subdomains makes it easier to understand, change and maintain each one independently.
Leverage: DDD encourages different software strategies to build flexible, testable and maintainable code.
And the drawbacks:
Learning Curve: Developers must have a deep understanding of the domain and business logic, in addition to the various software concepts involved.
Complexity: DDD is focused on tackling complex business scenarios. Project members have to spend considerable time designing the system and defining the correct vocabulary to use throughout the project.
Easy to do wrong: "The success of DDD relies on fostering a collaborative environment that encourages open communication between developers, domain experts, and stakeholders." The Ultimate Guide to Domain-Driven Design | AppMaster
Check out my video:
Comments