Domain Classes vs DTOs: Finding the Right Balance

In Domain-Driven Design (DDD), we often struggle with how to handle data transfer between our rich domain model and external systems or layers. Let's explore the relationship between domain classes and Data Transfer Objects (DTOs), and examine different approaches to mapping between them.

Domain Classes: The Heart of Your Business Logic

Domain classes represent your business entities and encapsulate both data and behavior. In DDD, these classes are the cornerstone of your domain model. Here's an example of a domain class:

public class Order
{
    private readonly List<OrderLine> _orderLines = new();

    public Guid Id { get; private set; }
    public Customer Customer { get; private set; }
    public OrderStatus Status { get; private set; }
    public IReadOnlyCollection<OrderLine> OrderLines => _orderLines.AsReadOnly();

    public Order(Customer customer)
    {
        Id = Guid.NewGuid();
        Customer = customer;
        Status = OrderStatus.Draft;
    }

    public void AddOrderLine(Product product, int quantity)
    {
        if (Status != OrderStatus.Draft)
            throw new InvalidOperationException("Can only add lines to draft orders");

        var line = new OrderLine(product, quantity);
        _orderLines.Add(line);
    }

    public void Submit()
    {
        if (!_orderLines.Any())
            throw new InvalidOperationException("Cannot submit empty order");

        Status = OrderStatus.Submitted;
    }
}

This domain class enforces business rules, maintains invariants, and provides a rich behavioral interface. However, it's not well-suited for data transfer or serialization.

DTOs: Light-Weight Data Containers

DTOs are simple objects designed for data transfer. They're immutable, have no behavior, and are optimized for serialization:

public record OrderDto
{
    public Guid Id { get; init; }
    public Guid CustomerId { get; init; }
    public string Status { get; init; }
    public IReadOnlyCollection<OrderLineDto> OrderLines { get; init; }
}

public record OrderLineDto
{
    public Guid ProductId { get; init; }
    public int Quantity { get; init; }
    public decimal UnitPrice { get; init; }
}

Mapping Approaches

1. Manual Mapping

The simplest approach is manual mapping:

public static class OrderMapper
{
    public static OrderDto ToDto(Order order)
    {
        return new OrderDto
        {
            Id = order.Id,
            CustomerId = order.Customer.Id,
            Status = order.Status.ToString(),
            OrderLines = order.OrderLines.Select(line => new OrderLineDto
            {
                ProductId = line.Product.Id,
                Quantity = line.Quantity,
                UnitPrice = line.UnitPrice
            }).ToList()
        };
    }
}

Benefits:

Complete control over the mapping process
Easy to debug
No external dependencies
Clear and explicit

Drawbacks:

Repetitive code
Maintenance overhead
Risk of missing properties during updates

2. Automatic Mapping with AutoMapper

AutoMapper provides a more automated approach:

public class OrderProfile : Profile
{
    public OrderProfile()
    {
        CreateMap<Order, OrderDto>()
            .ForMember(dst => dst.CustomerId, 
                      opt => opt.MapFrom(src => src.Customer.Id));

        CreateMap<OrderLine, OrderLineDto>()
            .ForMember(dst => dst.ProductId,
                      opt => opt.MapFrom(src => src.Product.Id));
    }
}

Benefits:

Less boilerplate code
Consistent mapping conventions
Compile-time checking of mappings
Easy to add new properties

Drawbacks:

Magic strings in older versions
Performance overhead
Can hide complex mapping logic
Learning curve for configuration

3. Domain Classes with DTO Methods

Another approach is to add DTO conversion methods to domain classes:

public class Order
{
    // ... existing domain logic ...

    public OrderDto ToDto()
    {
        return new OrderDto
        {
            Id = Id,
            CustomerId = Customer.Id,
            Status = Status.ToString(),
            OrderLines = OrderLines.Select(line => line.ToDto()).ToList()
        };
    }
}

Benefits:

Encapsulation of mapping logic
Strong typing
Easy to maintain alongside domain logic

Drawbacks:

Mixes concerns in domain class
Can bloat domain classes
Tight coupling to DTO structure

Best Practices and Recommendations

Keep Domain Classes Pure: Domain classes should focus on business logic and behavior. Avoid polluting them with serialization or mapping concerns.
Design DTOs for Specific Use Cases: Instead of creating one-to-one mappings with domain classes, design DTOs for specific use cases or API contracts.

public record OrderSummaryDto
{
    public Guid Id { get; init; }
    public string CustomerName { get; init; }
    public decimal TotalAmount { get; init; }
}

Use Mapping Layers: Create dedicated mapping layers or services to handle the transformation:

public interface IOrderMapper
{
    OrderDto ToDto(Order order);
    OrderSummaryDto ToSummaryDto(Order order);
}

Consider Performance: For high-performance scenarios, manual mapping might be preferred over automatic mapping tools.
Validate DTOs Separately: Add validation attributes or implement custom validation for DTOs independently of domain validation:

public record CreateOrderDto
{
    [Required]
    public Guid CustomerId { get; init; }

    [MinLength(1)]
    public List<CreateOrderLineDto> OrderLines { get; init; }
}

Conclusion

The choice between different mapping approaches depends on your specific needs:

Use manual mapping for simple scenarios or when performance is critical
Consider AutoMapper for larger applications where maintenance is a bigger concern
Use domain methods for mapping when the transformation is an integral part of the domain logic

Remember that DTOs and mapping are implementation details that should serve your domain model, not the other way around. Always design your domain model to express business concepts and behaviors clearly, then figure out how to map that to the outside world.

The key is finding the right balance between maintainability, performance, and clarity for your specific context. Don't be afraid to mix approaches where it makes sense - you might use AutoMapper for simple CRUD operations while maintaining manual mapping for complex transformations.