DDD(Domain Driven Design)-3 Key elements of DDD

DDD(Domain Driven Design)-2 Apply DDD to design microservice architectures that genuinely satisfy our business evolution needs

In the previous post, I discussed the Domain and Subdomain concepts of DDD and what we need to avoid when we define them.

To better elaborate on my next post regarding various software architecture styles and how we can integrate DDD with some of them, I will explain the critical concepts of DDD in this article.

Ubiquitous Language

Ubiquitous Language is the Domain-driven design term that describes common, rigorous language that developers and stakeholders share within specific boundaries.

It helps teams develop standardized terms and language so that all stakeholders have a consensus. It aims to assist us as product managers/owners, QAs, developers, and architects in accurately expressing business and understanding requirements.

I used to work for a telecom company, and my project has the term MVP. MVP generally stands for minimal viable product, but within our project scope, it refers to managed voice platform. It will bring confusion if we don’t clearly define it. That’s why we need Ubiquitous Language.

Bounded Context

Bounded Context is the boundary within a domain where a particular domain model and ubiquitous language apply. It is the central pattern of DDD that helps us avoid ambiguity and uncertainty in our software development.

Domain Model

Domain model is a structured visual representation of interconnected concepts or real-world objects that incorporates vocabulary, key concepts, behaviours, and relationships of all its entities. 

In a business logic implementation, a domain model is presented as a business object model, which describes the interconnected relationship between our business objects.

Business Objects(BO)

A BO model generally has 3 main components: business roles, business entities, and business use-case.

Business Roles: The roles play in our projects/systems, possessing inherent properties and a series of responsibilities, e.g., E-commerce customer service staff responsible for answering sale inquiries, order management, refund, product return, etc.

Business Entities: The components that are necessary for business roles’ interaction, e.g., product and invoice in an E-commerce project.

Business use-case: The workflow that business roles and business entities work together to execute, e.g., the action chain of product searching, product browsing, ordering, payment, deduction from inventory, invoicing, and delivery.

These 3 components together form a business object model.

4 categories of domain models

Blood Loss Model

1. Classes with only get and set without other logic, not even a simple sorting method.
2. Pros: It has a simple structure.
3. Cons:
   • It is hard to maintain with inflated business logic
   • It is hard to satisfy frequent changing requirements as it doesn’t have the Dao layer. All logics, including implementation code associated with JDBC invocation, reside in the service layer.

Anemia Model

1. Classes added atomic domain logic based on the Blood loss model, such as sorting and pagination methods.
2. Classes have attributes and innate behaviors/methods(i.e., belong to the domain model without persistence needs).
3. Other logic or non-innate behaviors that require database interaction resides in the business logic layer.
4. It is the recommended model by the Spring ecosystem.
5. Pros:
   • It has a clear layer structure.
   • It has single-direction dependency across layers.
   • It is easy to understand and brings fast development benefits for applications with smile business logic.
6. Cons:
   • It can’t gracefully cope with highly complicated logic and business scenarios.
   • It has low cohesion in projects’ core domains.
   • It doesn’t comply with some object-oriented programming principles.

Congestion Model

1. It is more in line with object-oriented programming principles than the Anemia model.
2. Domain objects contain both inherent and non-inherent logic. The business logic layer is only responsible for consolidation operations and transaction encapsulation, while domain objects take care of other operations.
3. Pros:
   • It has a thinner business logic layer, which is more in line with the single responsibility principle.
   • The business logic layer doesn’t interact with the Dao layer.
4. Cons:
   • It requires engineers to have robust implementation and design skills because it’s difficult to distinguish whether we should put specific business logic in the business logic layer or domain objects in particular scenarios.
     • We will need to write business logic to domain objects in some scenarios. Unfortunately, it could lead to cascading errors if we create some bugs during the process.
   • A higher cost to hire better engineers compared to using the Anemia model is one of the main reasons the Anemia model is more popular.
   • It has a higher instantiation cost, as many operations reside in the domain model.

Bloating Model

1. It has a simple layer structure.
2. There’s no service layer in the bloating model, only domain objects and Daos.
3. Domain objects and their methods take care of transactional operations, authorization, etc.
4. Pros:
   • It has a simple architecture layer.
   • It complies with object-oriented programming principles.
5. Cons:
   • As domain objects contain business logic and many other responsibilities, the code maintainability is terrible.
   • As domain objects’ domain logic takes care of transaction encapsulation and authorization, it contains some logic that does not necessarily belong to the domain objects causing greater code complexity compared to other models.
   • Engineers might need to refactor and redesign the domain model over time as increased requirements changes would cause logical chaos and unstable domain models.

Decision-Making Overview

The Anemia model is the most popular model which Spring ecosystem recommends. In contrast, the Congestion model has higher requirements for the dev teams, better system cohesion, and is suitable for businesses with straightforward business logic, such as businesses in the insurance industry.

Preview of next post

My next blog post will discuss the features, pros, and cons of the MVC architectural pattern, 3-tier architecture, 4-tier architecture, 5-tier architecture, hexagonal architecture, and more. After the discussion, I will elaborate on the architectural pattern solution that can gracefully integrate with the DDD approach.

See you in my next post.