Архитектура

Введение

PKirillW

25 окт. 2026 • 4 min read

Введение

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

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

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

Стратегическое проектирование: определение границ и контекстов

На этапе стратегического проектирования в Domain-Driven Design (DDD) основной задачей является декомпозиция сложной системы на управляемые части. Без четкого разграничения ответственности архитектура неизбежно превращается в «Big Ball of Mud», где изменение в одной функциональной области вызывает непредсказуемые побочные эффекты в других.

Идентификация поддоменов

Первым шагом является разделение системы на поддомены — крупные функциональные области. Это позволяет распределить ресурсы и команды:

Core Domain — уникальная бизнес-логика, приносящая основную ценность.
Supporting Domain — вспомогательные функции (например, управление складом).
Generic Domain — стандартные решения (авторизация, уведомления), которые лучше использовать как готовые сервисы.

Bounded Contexts и Ubiquitous Language

Внутри поддоменов мы определяем Bounded Contexts (ограниченные контексты). Это границы, внутри которых определенные модели данных и термины имеют строго фиксированное значение. Ключевым инструментом здесь является Ubiquitous Language — единый словарь понятий для разработчиков и предметных экспертов (Domain Experts).

Например, объект «Товар» в контексте Продаж содержит цену и описание, а в контексте Логистики — габариты и вес. Использование одного и того же класса для обеих целей приведет к утечке бизнес-логики:

# Пример нарушения границ: одна модель для разных смыслов
class Product:
    def __init__(self, name, price, weight, dimensions):
        self.name = name          # Продажи
        self.price = price         # Продажи
        self.weight = weight       # Логистика
        self.dimensions = dimensions # Логистика

# В DDD правильнее разделить их на разные контексты:
class SalesProduct:
    def __init__(self, name, price): ...

class LogisticsItem:
    def __init__(self, weight, dimensions): ...

Context Mapping

Для описания взаимодействия между контекстами используется Context Mapping. Он определяет стратегии интеграции:

Shared Kernel — совместное использование части кода или базы данных (использовать с осторожностью).
Customer/Supplier — один контекст является потребителем, другой — поставщиком (через API или очереди).
Conforming Subdomain — когда команда одного контекста адаптирует свои процессы под требования другого.

Тактическое проектирование: инструменты моделирования домена

Если стратегическое проектирование определяет границы системы, то тактическое — это набор инструментов для построения внутренней структуры этих границ. Оно позволяет перевести абстрактные бизнес-правила в конкретные программные конструкции.

Entities и Value Objects

Фундаментальное различие между ними заключается в идентичности:

Entities — объекты, обладающие уникальным идентификатором (ID). Их состояние может меняться во времени, но они остаются тем же самым объектом. Пример: пользователь или заказ.
Value Objects — неизменяемые структуры данных, которые определяются только своими атрибутами. Если два объекта Value Object имеют одинаковые значения, они считаются эквивалентными. Пример: адрес, сумма денег или цвет.

// Value Object (неизменяемый)
readonly class Money {
    public function __construct(
        public float $amount,
        public string $currency
    ) {}
}

// Entity (имеет ID и изменяемое состояние)
class Account {
    private Guid $id;
    private Money $balance;

    public function deposit(Money $money): void {
        $this->balance = $this->balance->add($money);
    }
}

Aggregates: границы целостности

Агрегат — это группа связанных объектов, которые рассматриваются как единая единица изменения. Aggregate Root (корень агрегата) является единственной точкой входа для внешних запросов. Основная задача агрегата — обеспечение соблюдения инвариантов (бизнес-правил), которые должны выполняться всегда.

Пример: при оформлении заказа система должна проверить наличие товаров на складе и заблокировать их. Весь этот процесс должен происходить внутри границы агрегата «Заказ», чтобы избежать состояний, когда товар списан, но заказ не создан.

Domain Services и Repositories

Не всякая логика может быть естественным образом встроена в сущности:

Domain Services используются для действий, которые затрагивают несколько агрегатов или не имеют четкого «хозяина». Они выполняют чисто бизнес-логику без побочных эффектов инфраструктуры.
Repositories предоставляют абстракцию доступа к данным. Репозиторий имитирует коллекцию объектов в памяти: он скрывает детали SQL-запросов или работу с NoSQL, возвращая готовые доменные объекты (Entities/Value Objects).

Factory методы

Создание сложных агрегатов часто требует выполнения сложной валидации и инициализации множества связанных сущностей. Factory инкапсулирует эту логику, гарантируя, что объект не будет создан в некорректном или «битом» состоянии. Это позволяет избежать раздувания конструкторов и соблюсти принцип единственной ответственности.

class OrderFactory {
    static createOrder(customer: Customer, items: Item[]): Order {
        if (items.length === 0) throw new Error("Order must have items");
        // Логика валидации и создания сложного агрегата
        return new Order(customer.id, items);
    }
}

Синхронизация стратегии и тактики: практическое применение

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

От Context Mapping к микросервисной архитектуре

Карта контекстов (Context Map) является фундаментом для проектирования распределенных систем. Каждая Bounded Context в идеале соответствует физической границе микросервиса. Если границы контекстов определены неверно, система неизбежно превратится в «распределенный монолит», где изменения в одном модуле вызывают каскадные ошибки в других.

Синхронная связь: Допускается только внутри одного контекста или между тесно связанными агрегатами.
Асинхронная связь: Используется для взаимодействия между независимыми контекстами, обеспечивая высокую степень изоляции.

Domain Events и Eventual Consistency

Для обеспечения слабой согласованности (Eventual Consistency) между контекстами используются Domain Events. Вместо того чтобы один сервис напрямую вызывал методы другого, он публикует событие о свершившемся факте в шине данных или брокер сообщений.

# Пример публикации события создания заказа
class OrderService:
    def create_order(self, order_data):
        order = Order.create(**order_data)
        repository.save(order)
        # Публикуем событие для других контекстов (например, Склада или Доставки)
        event_bus.publish("OrderCreated", {
            "order_id": order.id,
            "items": order.items
        })

Anti-Corruption Layer (ACL)

При интеграции с внешними системами или устаревшими API критически важно внедрить Anti-Corruption Layer. ACL выступает в роли переводчика: он преобразует данные внешней системы в терминологию вашего домена, не позволяя «грязным» моделям данных проникать внутрь бизнес-логики.

# Пример упрощенного ACL для интеграции с платежным шлюзом
class PaymentGatewayACL:
    def __init__(self, external_api):
        self.external_api = external_api

    def process_payment(self, internal_payment_request):
        # Преобразуем внутренний объект в формат стороннего API
        raw_data = self.external_api.post(
            amount=internal_payment_request.total,
            currency="USD"
        )
        # Возвращаем чистый доменный объект вместо сырого JSON
        return PaymentResult(success=raw_data['status'] == 200)

Тактика внутри границ: Агрегаты и паттерны

Внутри каждого контекста тактические паттерны (Repository, Factory, Service Layer) должны работать строго в рамках Aggregate Root. Важно избегать ситуации, когда логика одного агрегата напрямую модифицирует состояние другого. Если действие требует изменения данных в другом агрегате — это сигнал к использованию доменного сервиса или публикации события.

Агрегат отвечает за инварианты и целостность данных внутри своей границы.
Доменный сервис используется для логики, которая не принадлежит ни одному конкретному агрегату.
Репозиторий обеспечивает абстракцию доступа к данным, скрывая детали реализации БД от бизнес-логики.

Заключение

Эффективное применение Domain-Driven Design базируется на тонком балансе между стратегическим видением и детальной тактической реализацией. Успех архитектуры зависит от того, насколько точно границы контекстов соответствуют бизнес-процессам и как эти высокоуровневые концепции транслируются в конкретные инструменты моделирования — сущности, объекты-значения и агрегаты. Только при синхронизации стратегии и тактики программная система становится гибкой, понятной для бизнеса и способной к масштабированию без потери целостности кода.

При проектировании важно соблюдать принцип умеренности: уровень детализации DDD должен соответствовать сложности проекта — не стоит переусложнять простые сервисы избыточными паттернами. Для работы с существующими системами (Legacy) рекомендуется использовать итеративный подход к внедрению методологии. Постепенное выделение новых контекстов и постепенный перенос функционала позволяют минимизировать риски «взрывного» рефакторинга и обеспечивают плавную трансформацию системы в сторону чистого, доменно-ориентированного дизайна.