Признак нарушения архитектурных границ: чужой ID

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

Контекст

Конкретный пример.

Врач завершает осмотр и назначает следующий визит. Бэк мобильного приложения (BFF) сохраняет протокол осмотра и вызывает сервис задач. Тот бронирует время в календаре врачей и создаёт задачу на следующий визит.

Затем BFF вызывает сервис подтверждения записи, передавая ID протокола и ID бронирования. Подтверждение связывает бронь с состоявшимся осмотром. По правилам бизнеса такую бронь уже нельзя отменять, хотя технически это возможно.

Бронированием занимается сервис задач, а подтверждением – BFF. Поэтому сервис задач вынужден вернуть клиенту ID, полученный от календаря.

Проблема

Календарь - общедоступный сервис, но для сервиса задач является особенностью его текущей реализации. Идентификатор брони стал частью публичного контракта между ограниченными контекстами разных команд. Вместе с ним наружу вышла зависимость от устройства календаря.

Чем это грозит?

• Излишняя связанность. BFF участвует в бизнес-процессе, часть которого скрыта внутри сервиса задач. Стоит проверить, обосновано ли такое разделение ответственности.
• Хрупкость контракта. При замене календаря могут измениться формат и смысл ID. Тогда изменения затронут всех его потребителей.
• Рассогласование данных. При наличии доступа внешние системы могут изменить бронь по её ID в обход сервиса задач и нарушить связь между задачей и записью календаря.

Выявление проблемы

Признак нарушения границ:

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

Признак удобен при проведении ревью и подталкивает к обсуждению вопросов ответственности и стоимости будущих изменений:

• Откуда пришёл ID?
• Зачем он потребителю?
• Является ли ID частью общесистемного контракта?

Это согласуется с идеей защищать потребителей от изменений за стабильным контрактом.

Варианты решения

Вариантов много, вот основные:

• Оркестратор. Отвечает за завершение всего сценария и обработку частичных сбоев. Опционально: передать подтверждение сервису задач, если весь сценарий входит в его ответственность, тогда BFF получает результат без ID календаря.
• Собственный ID. Сервис задач хранит соответствие между своим ID и ID календаря. Это отделяет публичный контракт от идентификаторов зависимости. Однако придётся адаптировать подтверждение: оно пока ожидает ID календаря. Обход сервиса задач потребует специально “добывать” исходный ID и строить отдельную интеграцию. Это усложняет и удорожает обход, вызывает вопросы при реализации и помогает удерживать границу. Но не заменяет контроль доступа.
• Контроль доступа. Ограничить изменение броней, созданных сервисом задач, разрешёнными участниками процесса. Отдельно обеспечить проверку бизнес-запрета отмены подтверждённой брони. Это ограничивает обходные изменения, но требует настройки прав и специфичных проверок; зависимость публичного контракта от календаря остаётся.
• Общесистемный контракт. Осознанно оставить ID календаря в API, договорившись о его смысле, стабильности и правилах изменения броней. Меньше переделок сейчас, но сильнее связанность.

Как выбрать

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

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

Короче, старайтесь не выносить сор из избы :)