Зачем нужен DDD?

Зачем нужен Domain-Driven Design (DDD)?

Domain-Driven Design (DDD) — это методология разработки программного обеспечения, которая фокусируется на моделировании бизнес-домена (предметной области) и его сложностях. Основная цель DDD — преодолеть разрыв между технической реализацией и бизнес-требованиями, создавая гибкие, масштабируемые и легко поддерживаемые системы. Вот ключевые причины, почему DDD необходим:

1. Сложность бизнес-домена

В современных приложениях, особенно в корпоративной среде (например, финансы, логистика, e-commerce), бизнес-логика становится крайне сложной. DDD предлагает инструменты для структурирования и понимания этой сложности через:

• Единый язык (Ubiquitous Language) — общую терминологию, используемую разработчиками, бизнес-аналитиками и заказчиками для уменьшения недопониманий.
• Разделение домена на поддомены (Bounded Contexts) — изолированные части системы с четкими границами, что упрощает работу с разными аспектами бизнеса.

Пример кода на C# для простого домена "Заказ":

// Ubiquitous Language: Заказ (Order), Товар (Product), Статус (Status)
public class Order
{
    public Guid Id { get; private set; }
    public DateTime CreatedAt { get; private set; }
    public OrderStatus Status { get; private set; }
    private List<OrderItem> _items = new();
    public IReadOnlyCollection<OrderItem> Items => _items.AsReadOnly();

    // Бизнес-правило: нельзя добавить товар в завершенный заказ
    public void AddItem(Product product, int quantity)
    {
        if (Status == OrderStatus.Completed)
            throw new InvalidOperationException("Нельзя изменить завершенный заказ.");
        
        _items.Add(new OrderItem(product.Id, quantity));
    }
}

public enum OrderStatus { Pending, Completed, Cancelled }

2. Долгосрочное поддержание качества кода

Без DDD бизнес-логика часто "размазывается" по кодовой базе (например, в контроллерах или слое доступа к данным). Это приводит к:

• Спагетти-коду — сложностям в тестировании и изменениях.
• Хрупкости системы — любая правка вызывает непредвиденные побочные эффекты.

DDD решает это через архитектурные паттерны, такие как:

• Слоистая архитектура (Domain, Application, Infrastructure, Presentation).
• Сущности (Entities) и Объекты-значения (Value Objects) для инкапсуляции данных и поведения.
• Агрегаты (Aggregates) — группы связанных объектов, управляемых как единое целое.

// Value Object: Денежная сумма с валидацией
public record Money
{
    public decimal Amount { get; }
    public string Currency { get; }

    public Money(decimal amount, string currency)
    {
        if (amount < 0) throw new ArgumentException("Сумма не может быть отрицательной.");
        if (string.IsNullOrEmpty(currency)) throw new ArgumentException("Валюта обязательна.");

        Amount = amount;
        Currency = currency.ToUpper();
    }

    // Бизнес-операция: сложение денег с проверкой валюты
    public Money Add(Money other)
    {
        if (Currency != other.Currency)
            throw new InvalidOperationException("Нельзя складывать разные валюты.");
        
        return new Money(Amount + other.Amount, Currency);
    }
}

3. Адаптивность к изменениям

В Agile-среде требования часто меняются. DDD позволяет быстро реагировать на изменения бизнеса благодаря:

• Изоляции доменной логики от инфраструктурных деталей (баз данных, внешних сервисов).
• Тестируемости — доменные объекты можно тестировать без зависимостей.

Пример использования репозитория (инфраструктурный слой) в доменном сервисе:

// Доменный сервис для бизнес-процесса
public class OrderService
{
    private readonly IOrderRepository _repository;

    public OrderService(IOrderRepository repository)
    {
        _repository = repository;
    }

    public void CompleteOrder(Guid orderId)
    {
        var order = _repository.GetById(orderId); // Инфраструктурная деталь абстрагирована
        order.MarkAsCompleted(); // Чистая бизнес-логика
        _repository.Save(order);
    }
}

4. Масштабирование команды

DDDD помогает распределять работу в больших командах за счет:

• Bounded Contexts — разные команды могут работать над независимыми контекстами, минимизируя конфликты.
• Модульности — система делится на компоненты с низкой связанностью.

Когда DDD особенно полезен?

• Сложные бизнес-процессы с множеством правил и состояний.
• Долгосрочные проекты (от 1–2 лет), где важна поддерживаемость.
• Большие команды (5+ разработчиков), требующие координации.

Когда DDD может быть избыточным?

• Для простых CRUD-приложений без сложной логики.
• Прототипы или стартапы с неопределенными требованиями.

Вывод: DDD нужен для борьбы со сложностью бизнес-домена, повышения качества кода и обеспечения гибкости системы. Хотя он требует дополнительных усилий на проектирование, его применение окупается в долгосрочной перспективе за счет снижения затрат на поддержку и ускорения разработки новых функций.