1.3 Domain-Driven Design: Domain Design

Domain-Driven Design (DDD) emphasizes creating a software model that accurately reflects the business domain. This article explores the key aspects of domain design in DDD.

1. Building Entities and Values

Entities

Entities are objects with a distinct identity that persists over time and through different states. Examples include Customer, Order, and Product.

Key considerations:

• Identify entities by unique identifiers, not attributes
• Ensure entity equality is based on identity
• Focus entities on core attributes and behaviors

Consider this simplified C# example:

public class Order
{
    public Guid Id { get; private set; }
    public Customer Customer { get; private set; }
    public OrderStatus Status { get; private set; }

    public Order(Guid id, Customer customer)
    {
        Id = id;
        Customer = customer;
        Status = OrderStatus.Created;
    }

    public void SubmitOrder()
    {
        // Business logic for order submission
        Status = OrderStatus.Submitted;
    }
}        

Value Objects

Value objects are immutable objects that describe characteristics or attributes without a conceptual identity. Examples include Address, Money, and DateRange.

Key points:

• Implement value objects as immutable
• Use them to encapsulate related attributes and behavior
• Consider them for complex calculations or validations

2. Creating Domain Services

Domain services encapsulate domain logic that doesn't naturally fit within a single entity or value object. They are typically stateless operations that coordinate between multiple domain objects.

Examples of domain services:

• TransferMoneyService
• InventoryAllocationService
• PricingService

Best practices:

• Use domain services sparingly
• Focus on domain logic, not application or infrastructure concerns
• Name services using verbs or verb phrases to reflect their behavior

3. Designing Interfaces

Interfaces play a crucial role in DDD by defining contracts between different parts of the domain model.

Types of interfaces in DDD:

• Repository interfaces: For data access and persistence
• Factory interfaces: For creating complex domain objects
• Service interfaces: For defining domain service contracts

Consider this example of a repository interface:

public interface IOrderRepository
{
    Order GetById(Guid id);
    void Save(Order order);
    IEnumerable<Order> GetByCustomer(Guid customerId);
}        

Best practices for interface design:

• Keep interfaces cohesive and focused on a single responsibility
• Use the Ubiquitous Language in interface naming and method signatures
• Design interfaces around behavior rather than data
• Apply the Interface Segregation Principle to avoid large, monolithic interfaces

Conclusion

Domain design is a critical aspect of DDD, focusing on creating a rich, expressive model that captures the essence of the business domain. By carefully designing entities, value objects, domain services, and interfaces, developers can create a flexible and maintainable domain model that evolves with the understanding of the business.

It's important to remember that domain design is an iterative process. As insights into the domain deepen, the model should be refined and refactored to better represent the business reality. Regular collaboration between domain experts and developers is key to maintaining an accurate and useful domain model.

By applying these principles and patterns, teams can create software that not only meets technical requirements but also aligns closely with business needs and processes.