Что такое богатая доменная модель?

Что такое богатая доменная модель?

Богатая доменная модель (Rich Domain Model, RDM) — это ключевой паттерн в доменно-ориентированном проектировании (Domain-Driven Design, DDD), при котором основная бизнес-логика приложения инкапсулируется внутри сущностей (Entities) и объектов-значений (Value Objects), а не выносится в отдельные сервисные классы. Эта модель противопоставляется анемичной доменной модели (Anemic Domain Model), где объекты данных являются лишь контейнерами для свойств без поведения.

Основные принципы богатой доменной модели

1. Инкапсуляция бизнес-логики: Все правила и операции, относящиеся к конкретной сущности, реализуются внутри её методов.
2. Самодостаточность объектов: Сущности способны самостоятельно управлять своим состоянием и обеспечивать целостность данных.
3. Минимизация зависимостей: Бизнес-логика не зависит от внешних сервисов (например, баз данных или внешних API), что упрощает тестирование и поддержку.

Пример: анемичная vs богатая модель

Рассмотрим упрощённый пример с объектом Заказ (Order) в системе электронной коммерции.

Анемичная модель (нежелательный подход):

public class Order
{
    public int Id { get; set; }
    public decimal TotalAmount { get; set; }
    public OrderStatus Status { get; set; }
    public List<OrderItem> Items { get; set; }
}

public class OrderService
{
    public void ApplyDiscount(Order order, decimal discount)
    {
        if (order.Status != OrderStatus.Pending)
            throw new InvalidOperationException("Скидка применима только к pending заказам.");
        
        order.TotalAmount -= discount;
    }
    
    public void AddItem(Order order, OrderItem item)
    {
        order.Items.Add(item);
        order.TotalAmount += item.Price * item.Quantity;
    }
}

Здесь Order — это просто структура данных, а логика вынесена в OrderService. Это приводит к размыванию ответственности и усложняет понимание бизнес-правил.

Богатая модель (предпочтительный подход):

public class Order
{
    public int Id { get; private set; }
    public decimal TotalAmount { get; private set; }
    public OrderStatus Status { get; private set; }
    private readonly List<OrderItem> _items = new();
    public IReadOnlyCollection<OrderItem> Items => _items.AsReadOnly();

    public void ApplyDiscount(decimal discount)
    {
        if (Status != OrderStatus.Pending)
            throw new InvalidOperationException("Скидка применима только к pending заказам.");
        
        TotalAmount -= discount;
    }

    public void AddItem(OrderItem item)
    {
        _items.Add(item);
        TotalAmount += item.Price * item.Quantity;
    }

    public void MarkAsPaid()
    {
        if (TotalAmount <= 0)
            throw new InvalidOperationException("Заказ не может быть оплачен с нулевой суммой.");
        
        Status = OrderStatus.Paid;
    }
}

В этой реализации:

• Состояние защищено (сеттеры приватные).
• Логика инкапсулирована внутри методов класса.
• Гарантируется целостность (например, нельзя оплатить заказ с нулевой суммой).

Преимущества богатой доменной модели

• Чистота архитектуры: Чёткое разделение ответственности между слоями приложения.
• Упрощение тестирования: Бизнес-правила тестируются изолированно через публичные методы сущностей.
• Безопасность: Контроль над изменением состояния предотвращает некорректные операции.
• Гибкость: Легко добавлять новые правила, не затрагивая другие части системы.

Сложности реализации

1. ORM-маппинг: Требует аккуратной настройки (например, в Entity Framework) для работы с приватными сеттерами и коллекциями.
2. Производительность: Избыточная инкапсуляция может привести к дополнительным запросам к базе данных, если не оптимизировать загрузку данных.
3. Когнитивная нагрузка: Может показаться излишней для простых CRUD-приложений.

Практические рекомендации для C# Backend

• Используйте конструкторы для инициализации обязательных полей.
• Применяйте паттерн "Агрегат" (Aggregate) из DDD для управления целостностью связанных сущностей.
• Для сложных операций, затрагивающих несколько агрегатов, используйте доменные сервисы (Domain Services), но без выноса базовой логики из сущностей.

Богатая доменная модель особенно эффективна в сложных системах с интенсивной бизнес-логикой, где критически важны чистота кода, масштабируемость и тестируемость. Однако для простых приложений она может избыточна — здесь стоит оценивать компромисс между сложностью реализации и долгосрочными преимуществами.