Что такое DDD (Domain-Driven Design) и как можно применить этот подход на практике?

Question

DDD (Domain-Driven Design) — это подход к разработке программного обеспечения, который фокусируется на сложной предметной области (домене). Его основная идея — максимально точно смоделировать в коде бизнес-процессы, правила и понятия, используя общий язык между разработчиками и экспертами.На практике его применяют через:Глубокое погружение в домен: Постоянное общение с бизнес-экспертами.Создание единого языка (Ubiquitous Language): Использование одних и тех же точных терминов (например, "Портфель заказов", "Инвойс", "Сборка") в разговорах, документах и коде.Выделение bounded context (ограниченных контекстов): Чёткое разделение большой системы на относительно независимые модули, каждый со своей внутренней моделью (например, "Контекст логистики" и "Контекст биллинга").

YeaHub · Accepted Answer

1. Домен (Domain) и Единый язык (Ubiquitous Language)Домен — это предметная область, ради которой создаётся система (банкинг, логистика, электронная коммерция).Единый язык — это сердце DDD. Это словарь терминов, правил и понятий, который совместно создают и используют разработчики и эксперты-предметники. Этот язык используется везде: в беседах, документах, названиях классов и методов.Плохо (без языка): processTransaction(), checkStatus()Хорошо (с языком домена): approveLoanApplication(), dispatchCargoToPort()2. Ограниченный контекст (Bounded Context)Определение — это чёткая граница, внутри которой определённая модель (единый язык) имеет конкретное значение и является согласованной.Зачем это нужно: Один и тот же термин в разных частях системы может иметь разный смысл. Например, "Продукт" в контексте Каталога — это его название, фото и описание. В контексте Логистики — это его габариты, вес и код для сканирования.Практика: Разделение монолита на микросервисы часто проводится именно по границам bounded context.3. Сущности (Entities), Объекты-значения (Value Objects) и Агрегаты (Aggregates)Сущность: Объект, имеющий идентичность, которая сохраняется на протяжении всего жизненного цикла (например, Пользователь с ID). Две сущности равны, если их ID равны, даже если все другие данные разные.Объект-значение: Объект, не имеющий идентичности. Он описывается своими атрибутами (например, Денежная сумма с валютой и значением). Два объекта-значения равны, если равны все их атрибуты.Агрегат: Кластер из связанных сущностей и объектов-значений, который рассматривается как единое целое для операций изменения. У агрегата есть корень (Aggregate Root) — главная сущность, через которую происходит всё взаимодействие с внешним миром.Пример: Агрегат "Заказ". Корень — сущность Order. Внутри него — список OrderItem (объекты-значения или сущности) и сущность DeliveryAddress. Изменять OrderItem можно только через методы корня Order.Как применить на практике (шаги)Event Storming (Штурм событий): Проведите совместный воркшоп с экспертами и разработчиками. На стикерах выпишите все бизнес-события (что произошло: "Заказ создан", "Товар зарезервирован"), команды, которые их вызывают, и агрегаты, которые затронуты. Это помогает выявить bounded context и единый язык.Определите bounded context: Нанесите выявленные контексты на контекстную карту (Context Map), чтобы увидеть, как они взаимодействуют между собой (например, через общий клиент/адаптер или публикуя события).Спроектируйте агрегаты внутри контекста: Для каждого контекста определите ключевые агрегаты, их корни и инварианты (бизнес-правила, которые всегда должны соблюдаться).Реализуйте на уровне кода: Создавайте классы, которые напрямую отражают понятия домена. Бизнес-логика инкапсулируется внутри этих классов, а не размазывается по сервисам.Пример кода (упрощённый агрегат Заказ):java// Корень агрегата - Order
public class Order {
    private OrderId id; // Сущность, идентификатор
    private CustomerId customerId;
    private List<OrderLine> lines; // Объекты-значения или внутренние сущности
    private OrderStatus status;

// Важный бизнес-метод, а не просто сеттер
    public void addItem(ProductId productId, Quantity quantity, Price price) {
        // Проверка инвариантов внутри агрегата
        if (this.status != OrderStatus.DRAFT) {
            throw new IllegalStateException("Cannot modify submitted order");
        }
        this.lines.add(new OrderLine(productId, quantity, price));
    }

public void submit() {
        // Другое бизнес-правило
        if (this.lines.isEmpty()) {
            throw new IllegalStateException("Cannot submit empty order");
        }
        this.status = OrderStatus.SUBMITTED;
        // Может генерировать Domain Event: OrderSubmittedEvent
    }
}Вывод: DDD — это не про технологии, а про правильное мышление и организацию кода вокруг бизнес-понятий. Его стоит применять для сложных систем с нетривиальной бизнес-логикой, где ошибки в её понимании дорого обходятся. Для простых CRUD-приложений он может быть избыточен. Основная выгода — создание гибкой, понятной и сопровождаемой модели, которая эволюционирует вместе с бизнесом.