Компания разрешает отгружать заказ несколькими партиями. На архитектурной схеме всё уже разделено: продажи, склад, расчёты. Интерфейсы существуют, владельцы известны. Но выясняется, что статус «отгружен» означает для склада передачу одной партии, а для расчётов — завершение всего заказа. Добавить ещё один статус недостаточно: нужно договориться, какое событие даёт право выставить счёт.
Context Mapping помогает увидеть такие отношения между моделями. Если Bounded Context определяет область согласованных понятий, карта контекстов показывает, как эти области зависят друг от друга, где переводится смысл и кто способен повлиять на изменение. Это не схема размещения серверов.
Стрелка запроса и направление зависимости могут не совпадать
Приложение продаж вызывает складское API, но сама стрелка вызова мало говорит о свободе команд. Если склад меняет определение отгрузки, а продажи вынуждены подстраиваться, склад занимает upstream-позицию в этом отношении. Потребитель оказывается downstream. Это направление влияния на модель и контракт, а не оценка важности подразделений.
В других отношениях те же участники могут поменяться ролями. Например, состав подтверждённого заказа задают продажи, и склад принимает его как основание комплектации. Не стоит присваивать системе одно универсальное положение «главной». На карте указывают конкретную связь и смысл зависимости. Такой взгляд на разные модели и их отношения описан у Мартина Фаулера.
Начните с существующего порядка, включая неудобные обходы. Если расчёты читают таблицу склада напрямую, а исправления согласуются только после поломки, это важнее предполагаемого будущего API. Желаемое состояние можно нарисовать отдельно; смешение двух карт мешает оценить объём перехода.
Какое влияние действительно есть у потребителя
Отношение Customer/Supplier означает, что потребности нижестоящего контекста учитываются в планировании поставщика. Это не просто факт получения данных. Для нашей отгрузки нужна договорённость, когда склад предоставит сведения о партиях и какие проверки подтверждают пригодность нового контракта для расчётов. Терминология отношений приведена в документации Context Mapper.
Если стороны могут успешно выпустить возможность только вместе, уместно признать партнёрство и совместно управлять этим изменением. Это честнее двух независимых планов, каждый из которых считает работу соседей уже выполненной. Совместное планирование не означает, что вся внутренняя модель должна стать общей.
У внешнего перевозчика условия могут быть другими: наши пожелания не определяют его дорожную карту. Можно сознательно принять его модель — Conformist, если она подходит продукту. А можно сохранить свою и поставить слой перевода. Второй вариант требует дополнительной работы, поэтому независимость нужно покупать для конкретного различия, а не ради названия паттерна.
Карта не даёт команде полномочий, которых у неё нет. Если поставщик не обещал изменить интерфейс к нужному сроку, подпись Customer/Supplier не превращает ожидание в обязательство. У решения должны появиться участники, согласованный объём и порядок разрешения конфликта приоритетов.
Зафиксировать значение, а не только поля
Для частичной отгрузки договоритесь, что именно передаётся: партия, строки заказа, количество и момент передачи. Может ли событие быть исправлено? Что означает отмена после физической отправки? Один и тот же текстовый статус в двух системах не гарантирует одинакового ответа.
Полезно записать ожидаемое поведение на примерах: первая партия ушла, вторая задержана, сведения о первой исправлены. Какой документ появляется в расчётах, что видит клиент и кто объясняет расхождение? Владелец факта об отгрузке не обязан владеть правилом выставления счёта. Их связь надо согласовать, не сливая две ответственности.
Для многочисленных потребителей поставщик может предложить устойчивый интерфейс и опубликованный язык обмена. Это помогает не проектировать отдельный формат для каждого соседа. Но язык обмена не обязан раскрывать все внутренние объекты склада. Пример такого отношения — Published Language — описывает договорённость на границе, а не единую модель всей компании.
Выбранное отношение не диктует транспорт. Перевод может выполняться внутри одного приложения, а договорённость потребителей — проверяться без отдельного брокера. Наоборот, два физических сервиса могут оставаться тесно связанными через общую модель. Поэтому рядом с отношением полезно указывать способ реализации, не подменяя первым второе.
Карта нужна и в день, когда данные не пришли
Отношения между командами определяют не только выпуск, но и восстановление. Если сведения о партии задержались, расчёты могут остановиться на предварительном состоянии. Для другого сценария потребуется проверка у источника. Допустимую задержку выбирают по обещанию клиенту; сама событийная интеграция этого решения не принимает.
При исправлении ошибочной отгрузки нужно понять, кто публикует уточнение, кто пересчитывает результат и какие уже выполненные действия требуют отдельного исправления. Сообщение в очереди не отменит отправленный документ. На карте полезно отметить ответственных, а подробный порядок сохранить рядом с контрактом.
К некоторым данным может не требоваться постоянная интеграция. Если отдельной задаче достаточно согласованного периодического отчёта, двусторонняя синхронизация всех объектов добавит обязательства без ясной пользы. При этом отчёт всё равно остаётся передачей данных со своими правилами: называть его полным отсутствием связи было бы неточно.
Проверить карту изменением, а не её полнотой
Не нужно начинать с описания каждой таблицы. Возьмите три участвующих контекста и отметьте владельцев моделей, значимые факты, способы обмена и реальные возможности договариваться. Отдельно обозначьте неизвестное: например, кто разрешает менять трактовку статуса.
Затем проведите частичную отгрузку через предложенный контракт. Контрактные тесты помогают проверять конкретные ожидания потребителя и поведение поставщика. Они дополняют примеры бизнес-результата, но не заменяют их: совместимый формат ещё может передавать неверно понятый факт.
После обсуждения должно стать понятно, что меняется совместно, что остаётся локальным и какие обещания пока не подтверждены. Обновлять карту удобно вместе с такими решениями. Если она нужна только на ежегодном архитектурном обзоре, скорее всего, рабочие договорённости уже живут где-то в другом месте.