← назад к разделу

Когда система вырастает, её делят на несколько независимых частей — Bounded Context. Каждая часть отвечает за свой кусок предметной области: заказы, доставка, оплата. Но части всё равно должны как-то взаимодействовать.

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

DDD описывает семь паттернов интеграции. Разберём каждый простыми словами.

Anti-Corruption Layer — защитный слой-переводчик

Представьте: ваш код заказов должен получать данные из старой платёжной системы. У неё своя терминология, свои поля, свой формат. Если тянуть её понятия прямо в свой код — в итоге ваш домен заказов начнёт говорить на языке платёжной системы. Поменяется платёжная — придётся переписывать домен.

Anti-Corruption Layer (ACL) — это слой-переводчик. Он принимает «чужой» формат и переводит его в понятия вашего домена. Снаружи — чужой мир, внутри — ваши типы.

// Порт — ваш домен описывает, что ему нужно
public interface PaymentGateway {
    PaymentOrder getPaymentStatus(PaymentOrderId id);
}

// ACL-адаптер — переводит чужой ответ в ваш тип
@Component
public class SberPaymentAdapter implements PaymentGateway {
    private final SberClient client;

    @Override
    public PaymentOrder getPaymentStatus(PaymentOrderId id) {
        SberPaymentResponse response = client.getOrderStatus(id.value());
        return new PaymentOrder(
            new PaymentOrderId(response.getOrderId()),
            Money.ofKopecks(response.getAmount()),
            mapStatus(response.getOrderStatus())
        );
    }
}

Смена платёжного провайдера затрагивает только адаптер. Домен заказов ничего не знает о Сбере — он работает через интерфейс PaymentGateway.

ACL применяется везде, где граница между «нашей» и «чужой» моделью существенна: внешние API, сторонние сервисы, соседние команды. В микросервисной архитектуре ACL — стандарт для каждой внешней интеграции.

Open Host Service — публичный API с устойчивым форматом

Обратная ситуация: не вы потребляете чужое, а другие потребляют ваше. Если вы просто «открываете» внутренние классы наружу — любое изменение модели ломает клиентов.

Open Host Service (OHS) — это когда контекст публикует стабильный документированный API. Внутренняя модель может меняться, а API остаётся предсказуемым.

Published Language — конкретный формат этого API: стабильные DTO, OpenAPI-схема, версионированный контракт.

// Стабильный контракт — Published Language
public record OrderJson(
    UUID orderId,
    String status,
    BigDecimal totalAmount,
    String currency,
    OffsetDateTime createdAt
) {}

// Контроллер публикует API, не доменную модель
@RestController
@RequestMapping("/api/v1/orders")
public class OrderApiController {
    @GetMapping("/{id}")
    public OrderJson getOrder(@PathVariable UUID id) {
        OrderDto dto = dispatcher.dispatch(new GetOrderQuery(id));
        return mapper.toJson(dto);  // маппер изолирует домен от контракта
    }
}

Клиенты зависят от OrderJson, а не от внутреннего класса Order. Добавили поле в Order — OrderJson не меняется, клиенты не ломаются.

В микросервисах это оформляется как OpenAPI-спецификация с версией в URL (/api/v1/, /api/v2/). Контракт проверяется контракт-тестами в CI.

Customer–Supplier — поставщик и потребитель

Один контекст поставляет данные или функциональность, другой потребляет. Поставщик (Supplier) решает, как и когда менять контракт. Потребитель (Customer) влияет на приоритеты, но не диктует условия.

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

// Supplier объявляет интерфейс
public interface ProductQueries {
    Optional<Product> findById(ProductId id);
}

// Customer получает его через внедрение зависимости
public class CreateOrderHandler {
    private final ProductQueries products;
    // ...
}

В микросервисах поставщик публикует REST или Kafka API, поддерживает SLA, ведёт журнал изменений. Потребитель — формальный клиент. Breaking changes поставщик согласует заранее.

Ключевое правило: изменение контракта — ответственность поставщика. Потребитель следит за журналом изменений, контракт-тесты проверяют совместимость автоматически.

Conformist — принятие чужой модели как есть

Иногда самый простой выход — использовать модель другой системы напрямую, без перевода. Это паттерн Conformist: мы принимаем чужой формат данных и не создаём свою модель поверх него.

Когда это оправдано: внешний API стабилен, меняется редко, его модель вас полностью устраивает.

// Используем модель ЦБ РФ напрямую — меняется раз в годы
public record CbrCurrencyRate(String code, BigDecimal rate, LocalDate date) {}

@Component
class CurrencyService {
    private final CbrClient cbrClient;

    public CbrCurrencyRate getRate(String code) {
        return cbrClient.getRate(code);  // никакого маппинга
    }
}

Conformist — это осознанный выбор, не лень. Если чужая модель начала меняться, в ваш домен стали проникать чужие термины, или вы хотите поддерживать несколько версий API — пора строить ACL.

Внутри системы (между своими модулями или сервисами) Conformist почти всегда плохая идея: ACL внутри одного процесса почти бесплатный, зато даёт изоляцию.

Shared Kernel — общая часть модели

Некоторые типы фундаментальны и нужны нескольким контекстам: идентификаторы, денежные суммы, базовые перечисления. Дублировать их в каждом модуле неудобно.

Shared Kernel — небольшая общая часть модели, которой совместно владеют контексты.

shared-kernel/
└── src/main/…/shared/
    ├── ids/UserId
    ├── ids/OrderId
    └── value/Money

Правило: в Shared Kernel только фундаментальные типы без бизнес-логики. Никаких агрегатов, никаких правил домена. Изменение типа в Shared Kernel требует согласования всех команд, которые его используют.

В монолите это просто общий модуль. В микросервисах — осторожно: общая библиотека связывает деплои всех сервисов. Если поменяли Money — надо пересобрать и выкатить все сервисы одновременно. Это называют «распределённым монолитом» и считают проблемой. Альтернатива: дублировать тип в каждом сервисе и передавать примитивы (UUID, String) на границах.

Partnership — совместная разработка

Два контекста развиваются вместе: обе команды совместно согласовывают изменения контракта, релизы координируются.

Это уместно, когда два модуля разрабатывает одна команда или две команды очень тесно сотрудничают. Нет формального «поставщика» — обе стороны равноправны.

// Оба модуля согласовали добавление нового поля
public record CreateOrderRequest(
    UUID customerId,
    List<OrderItemRequest> items,
    UUID warehouseId  // ← добавлено совместно Orders + Inventory
) {}

Риск: если команды разойдутся или появятся новые менеджеры — совместная разработка превращается в неконтролируемую связность. Сигнал к смене паттерна: ввести версионирование и перейти к Customer–Supplier.

Separate Ways — независимые пути

Иногда два контекста просто не должны знать друг о друге. Они решают разные задачи, даже если используют похожие данные.

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

Notification Service — своя таблица пользователей (email, телефон, настройки)
Analytics Service    — своя таблица посетителей (сегмент, последний визит)

Дублирование данных? Да. Но зато полная независимость: релизы, инциденты, деплои — всё отдельно. Иногда это правильный выбор.

Domain Events — как контексты сообщают о том, что произошло

Domain Events — не отдельный паттерн выбора связности, а механизм коммуникации. Контекст публикует событие о том, что произошло («Заказ подтверждён»), другой контекст реагирует.

В монолите события передаются внутри процесса через event bus. Spring предоставляет ApplicationEventPublisher:

@Service
class ConfirmOrderHandler {
    private final OrderRepository orders;
    private final ApplicationEventPublisher events;

    @Transactional
    public void handle(ConfirmOrderCommand cmd) {
        Order order = orders.findById(cmd.orderId());
        order.confirm();
        orders.save(order);
        events.publishEvent(new OrderConfirmed(order.getId(), order.getTotal()));
    }
}

@Component
class ShippingListener {
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    void on(OrderConfirmed e) {
        // Выполняется только после успешного коммита заказа
    }
}

Гарантия: если транзакция откатилась — слушатель не вызовется. @TransactionalEventListener(AFTER_COMMIT) гарантирует, что реакция произойдёт только при успешном сохранении.

В микросервисах события передаются через брокер сообщений (Kafka, RabbitMQ). Здесь возникает проблема: что если сервис сохранил заказ в базу, но упал до публикации события в Kafka? Событие потеряно.

Решение — Transactional Outbox: событие записывается в ту же базу данных в той же транзакции. Отдельный процесс (relay) читает события из базы и публикует в Kafka.

@Transactional
public void handle(ConfirmOrderCommand cmd) {
    Order order = orders.findById(cmd.orderId());
    order.confirm();
    orders.save(order);

    // Outbox — в той же транзакции, что и сохранение заказа
    outbox.save(OutboxEvent.of(
        "order.confirmed.v1",
        order.getId().toString(),
        new OrderConfirmedV1(order.getId(), order.getTotal())
    ));
}

// Отдельный процесс читает outbox и публикует в Kafka
@Scheduled(fixedDelay = 1000)
void publish() {
    outbox.findPending().forEach(e -> {
        kafka.send("order-events", e.payload());
        outbox.markPublished(e.id());
    });
}

Важно: Kafka доставляет события минимум один раз (at-least-once). Дубликаты возможны. Потребитель должен быть идемпотентным — проверять, не обработано ли событие уже.

Как выбрать паттерн

Простое дерево решений:

  • Нет интеграции → Separate Ways
  • Внешняя система, их модель устраивает → Conformist
  • Внешняя система, нужна защита домена → Anti-Corruption Layer
  • Один поставляет, много потребляют → Open Host Service + Published Language
  • Один поставляет, один потребляет → Customer–Supplier
  • Одна команда, два модуля → Partnership
  • Общие базовые типы → Shared Kernel (осторожно в микросервисах)

Частые ошибки

ACL «протекает». ACL принимает чужой тип и возвращает его наружу — защита не работает. Всегда маппируйте до границы ACL, наружу — только свои типы.

Shared Kernel разросся. В «общий» модуль попала бизнес-логика, агрегаты, правила. Теперь все зависят от всего. Shared Kernel — только фундаментальные примитивы.

Temporal coupling. Синхронная цепочка: сервис A вызывает B, B вызывает C. Упал C — сломалось всё. Domain Events + асинхронная обработка разрывают цепочку.

God Context. Один контекст знает про всех: хранит клиентов, заказы, доставку, оплату. Нет смысла в Bounded Context — всё в одном месте. Делите по ответственности.

Коротко

  • ACL — слой-переводчик между чужой моделью и вашим доменом. Защищает домен от внешних изменений.
  • Open Host Service + Published Language — стабильный публичный API, отделённый от внутренней модели.
  • Customer–Supplier — один поставляет, другой потребляет. Поставщик управляет контрактом.
  • Conformist — принятие чужой модели как есть. Оправдан для стабильных внешних API.
  • Shared Kernel — общие базовые типы. В монолите удобен, в микросервисах опасен.
  • Partnership — совместная разработка двух контекстов одной командой.
  • Separate Ways — без интеграции. Полная независимость ценой дублирования.
  • Domain Events — механизм оповещения: в монолите через event bus, в микросервисах через брокер + Transactional Outbox.

Что почитать дальше