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
Некоторые распространенные ошибки, которые стоит избегать:
  1. Использование DDD без реальной потребности – если проект не сложный, применение DDD только усложнит разработку.
  2. Неправильное определение границ контекста – слишком большие или размытые границы делают систему сложной.
  3. Игнорирование бизнес-экспертов – DDD требует активного взаимодействия с предметными экспертами.
  4. Излишняя усложненность модели – не все элементы 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