Anemic-domain vs Rich-domain Model Entities Entities in DDD w/ .NET 8 Microservices
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
andRemoveOrderItem
within theOrder
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. 🌟
I have just published course — .NET 8 Microservices: C# 12, DDD, CQRS, Vertical/Clean Architecture.
This is step-by-step development of reference microservices architecture that include microservices on .NET platforms which used ASP.NET Web API, Docker, RabbitMQ, MassTransit, Grpc, Yarp API Gateway, PostgreSQL, Redis, SQLite, SqlServer, Marten, Entity Framework Core, CQRS, MediatR, DDD, Vertical and Clean Architecture implementation with using latest features of .NET 8 and C# 12.