Domain Driven Design, also known as DDD, is a software design technique that employs the Business Domain as a guiding principle and models it as a means of communication between business experts and technology professionals.
Establishing a Ubiquitous Language
The first key point in DDD is to establish a Ubiquitous Language, which aims to be understood by both domain experts and developers, using terms that denote concepts, processes, and events from the real domain of the problem. A glossary can be created to ensure a shared understanding of terms in Use Cases, Features, Tasks, and other documentation.
Discovering the Domain
The actual domain of the problem is represented by the ubiquitous language, which is obtained through conversations with domain experts. The identification of the core domain, which is the fundamental part required to fulfill client requirements, and the understanding of the project’s goals are the tasks of the technology expert. Subdomains, which interact with the core domain, are also taken into consideration when analyzing the problem domain. Key concepts are modeled, responsibilities are separated to resemble the real problem, and entities that influence the problem are identified.
The emphasis is placed on the “real problem” to highlight that it is not solely based on client input or a single expert’s perspective. It encompasses all perspectives, providing a comprehensive view of the problem that software aims to address.
The Concept of DDD
The code is organized to clearly separate domain modeling from technical implementation details. This allows for easier handling of domain-related issues such as modifications or adding new functionalities while remaining technology-agnostic.
Components of DDD
- Entities: Representations of terms from the real domain, encompassing both data and behavior (e.g., User, Purchase, Receipt).
- Value objects: Components with attributes that do not exist independently but contribute to the modeling of a concept (e.g., address details within a purchase).
- Aggregates: Groups of related entities and value objects, facilitating management. (e.g The package user which group the class User and also the Address witch is related to the user and only to the User in this context)
- Domain Services: Business logic is encapsulated and grouped based on logical criteria. For example, a BankServices entity offers various banking-related services. Services may call other services to accomplish their tasks.
- Repository: Models data infrastructure, providing behavior for data management operations. Repository entities can be implemented using different technologies while adhering to the repository interface.
- Factories: Responsible for creating and initializing entities and aggregates, encapsulating creation logic for easier testing.
- Bounded Context: Addresses large models and teams. Bounded contexts define shared terms in different contexts, ensuring separate representations to avoid collateral effects from changes.
Architecture and Project Organization
Domain Driven Design does not specifically prescribe any particular architecture; instead, it places a strong emphasis on domain modeling concepts and the importance of effective communication. The choice of architecture, however, is dependent on various factors such as system requirements, context, and the preferences of the development team. Nevertheless, there exist numerous architectural options that can be effectively combined with DDD to facilitate the implementation of scalable and maintainable systems.
- Hexagonal Architecture (Ports and Adapters): Separates domain logic from infrastructure details, using ports and adapters to connect internal and external layers.
- Microservices Architecture: Divides the system into small, autonomous, and cohesive services, each representing a specific domain and communicating through well-defined interfaces.
- Service-Oriented Architecture (SOA): Builds reusable and distributed services that communicate using standard interfaces, enabling interoperability and independent evolution.
- Layered Architecture: Divides the application into logical layers, such as presentation, application, domain, and infrastructure, with each layer responsible for specific tasks.
Advantages of DDD
- Common language between domain experts and technology experts.
- Well-organized code, enabling separate testing of different domain parts.
- Centralized business logic divided into contexts.
- The domain model is separated from technology.
Disadvantages of DDD
- Acquiring a domain vision and isolating business logic can be time-consuming.
- Challenging to implement in existing systems without well-modeled alignment with the real problem.
- DDD introduces complex concepts and patterns, requiring additional effort to understand and apply correctly.
References:
Be First to Comment