Anemic-domain vs Rich-domain Model Entities Entities in DDD w/ .NET 8 Microservices

3 min readMar 27, 2024

We are going to learn develop DDD Rich-domain model Entity for Order Entities in Order.Domain Layer.

I have just published course — .NET 8 Microservices: C# 12, DDD, CQRS, Vertical/Clean Architecture.

🤔 The Order Entity Conundrum

When it comes to manipulating items within our Order aggregate, the choice of model can dramatically alter our approach. Let's consider a scenario:

Anemic Approach: Exposing OrderItems publicly allows unrestricted manipulation, a clear violation of encapsulation principles.
Rich-Domain Approach: Encapsulating AddOrderItem and RemoveOrderItem within the Order itself aligns with DDD principles, ensuring business logic resides where it naturally belongs.

🚀 Anemic-Domain Model Entity: A Brief Overview

The Anemic-domain model, characterized by its skeletal structure, reduces entities to mere data containers devoid of intrinsic business logic. This approach, while initially straightforward, scatters domain logic across the application, leading to a fragmented and less cohesive model.

Example Structure:

public class Order
{
    public List<OrderItem> OrderItems { get; set; }
    // Other properties...
}

💡 Rich-Domain Model Entity: Encapsulating Logic

The Rich-domain model breathes life into entities, infusing them with both data and behavior. This model ensures that entities are not just data structures but active participants in enforcing business rules and logic.

Enhanced Structure:

public class Order : Aggregate<Guid>
{
    private readonly List<OrderItem> _orderItems = new();
    public IReadOnlyList<OrderItem> OrderItems => _orderItems.AsReadOnly();
    public void AddOrderItem(OrderItem item)
    {
        // Domain logic to add an item
    }
    public void RemoveOrderItem(OrderItemId itemId)
    {
        // Domain logic to remove an item
    }
    // Other properties...
}

📊 Anemic vs. Rich Domain Model: The Comparison

In juxtaposing these models, we observe that while the Anemic model might offer initial simplicity, it fails to truly represent the business domain, leading to potential maintainability challenges.

The Rich domain model, though possibly more complex to design, results in a more maintainable and coherent model that closely mirrors real-world business intricacies.

🛠️ Practical Application: Rich-Domain Order Class

In practice, transforming the Order class into a Rich-domain model involves encapsulating logic for item manipulation within the Order class itself, adhering to business rules and preserving the integrity of the aggregate.

Practical Code Example:

📚 Diving into Ordering Microservices with DDD & Clean Architecture

Our journey navigates through the core essence and periphery of the Ordering system, revealing the blueprint of a system designed for resilience, flexibility, and domain-centricity.

🌈 Conclusion: Championing Rich-Domain Models

Transitioning to a Rich-domain model for the Order entity not only centralizes business logic but also fortifies our domain model against inconsistencies and breaches of business rules. This approach fosters a domain model that's not just robust but a true mirror of the business domain it represents.

Embrace the richness of domain modeling, for it is the beacon that guides us toward a more cohesive and expressive domain landscape. 🌟