DDD для начинающих: руководство и примеры

Введение

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

Основные принципы DDD

DDD основан на глубоком понимании предметной области и включает следующие ключевые концепции:

Предметная область (Domain) — это сфера деятельности, которую охватывает система (например, финансы, здравоохранение, логистика).
Модель (Model) — абстрактное представление предметной области, созданное совместно с бизнес-экспертами.
Единый язык (Ubiquitous Language) — общий язык, используемый разработчиками и бизнес-экспертами для общения.
Границы контекста (Bounded Contexts) — четкие границы, определяющие, где конкретная модель применима.

Стратегический и тактический DDD

DDD можно разделить на два уровня: стратегический и тактический.

Стратегический DDD

Стратегический DDD помогает управлять сложностью системы на высоком уровне. Основные концепции:

Bounded Contexts (Ограниченные контексты) — каждая модель должна иметь четкие границы.
Context Mapping (Картирование контекстов) — связи между ограниченными контекстами, такие как Shared Kernel, Customer-Supplier, Partnership.
Subdomains (Поддомены) — разделение предметной области на Основной (Core), Поддерживающий (Supporting) и Вспомогательный (Generic) поддомены.

Пример из практики: в одном из проектов по разработке ERP-системы мы разделили систему на несколько контекстов: «Управление заказами», «Финансы» и «Логистика». Это позволило каждой команде работать независимо, а интеграция между контекстами происходила через четко определенные API.

Тактический DDD

Тактический DDD определяет, как строить код в рамках ограниченного контекста. Основные элементы:

Entities (Сущности) — объекты с уникальным идентификатором.
Value Objects (Объекты-значения) — неизменяемые объекты без идентичности.
Aggregates (Агрегаты) — группы объектов с единым корнем управления.
Repositories (Репозитории) — классы для управления доступом к данным.
Services (Сервисы) — классы, содержащие логику, не относящуюся к сущностям.

Пример: В системе бронирования отелей мы использовали агрегат Booking, который содержал сущности Guest и Room, а также объект-значение DateRange. Это позволило четко разграничить ответственность и упростить валидацию бизнес-логики.

Пример реализации DDD на практике

Рассмотрим небольшой пример на языке Java, демонстрирующий применение DDD.

// Сущность Заказ (Order)
public class Order {
    private UUID id;
    private List<OrderItem> items;
    private OrderStatus status;
    
    public Order(List<OrderItem> items) {
        this.id = UUID.randomUUID();
        this.items = items;
        this.status = OrderStatus.CREATED;
    }
    
    public void confirm() {
        if (status == OrderStatus.CREATED) {
            this.status = OrderStatus.CONFIRMED;
        } else {
            throw new IllegalStateException("Невозможно подтвердить заказ");
        }
    }
}

// Объект-значение OrderItem
public class OrderItem {
    private String productId;
    private int quantity;
    
    public OrderItem(String productId, int quantity) {
        this.productId = productId;
        this.quantity = quantity;
    }
}

// Агрегатный корень
public class OrderAggregate {
    private OrderRepository repository;
    
    public void placeOrder(List<OrderItem> items) {
        Order order = new Order(items);
        repository.save(order);
    }
}

Этот код демонстрирует принципы DDD: сущности, объект-значение и агрегат.

Ошибки при внедрении DDD

Некоторые распространенные ошибки, которые стоит избегать:

Использование DDD без реальной потребности – если проект не сложный, применение DDD только усложнит разработку.
Неправильное определение границ контекста – слишком большие или размытые границы делают систему сложной.
Игнорирование бизнес-экспертов – DDD требует активного взаимодействия с предметными экспертами.
Излишняя усложненность модели – не все элементы DDD нужны в каждом проекте.

Выводы

DDD – мощный инструмент, который позволяет создавать понятные и масштабируемые системы. Однако его применение требует четкого понимания бизнес-логики и необходимости разделения системы на контексты. При правильном использовании DDD помогает улучшить архитектуру, снизить зависимость между модулями и упростить сопровождение кода.

Посмотреть программу

Эта тема подробно рассматривается на курсе "DDD и Clean Architecture на практике"

Понравилась статья? Поделись в соцсетях!

Our Website is Almost Ready

Launch a targeted campaign.
Scale your infrastructure with our simple service.

Days

Hours

Minutes

Seconds

Learn more