Намерения реализовать новую бизнес-логику автономно за рамками монолитной архитектуры часто разбиваются об отсутствие данных (назовем это явление missing data source или сокр. MDS).

Missing Data Source - это необходимый и отсутствующий на момент выноса/реализации нового сервиса (зависимый сервис) источник данных (пр. kafka-топик, эндпойнт в монолите/сервисе, подключение к БД). В целевой архитектуре источником выступает отдельный (со-зависимый) сервис, может отсутствовать на момент реализации (не вынесен из монолита).

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

💡Исходя из ситуации есть 3 стандартных подхода решения MDS (отсортированы от правильно-долгого к ужасно-быстрому):

1️⃣Идиоматичный
Необходимые данные передаются асинхронно в со-зависимый сервис, отвечающий за локализованную предметную область.

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

2️⃣Компромисный (отложенный перенос)
Сделать "временный топик" на базе монолита, сделав его контракт максимально совместимым с первым вариантом. В перспективе, при выносе зависимого сервиса продюсер данных переедет в него. Вполне идиоматичный вариант, если представить монолит - как большой сервис.

Минусы: полной совместимости с будущим решением может не получится, формат данных в топике может иметь "монолитный характер". Помимо декомпозиции контракта жирного топика и потребуются изменения всех потребителей (которых на этот момент может быть много).

3️⃣Синхронный
Реализуем временный API-на базе монолита (или ходим напрямую в его БД).

Минусы: получаем синхронную интеграцию и сильную связность, со всеми вытекающими

Из-за зависимости одного несуществующего сервиса от другого, на практике сделать сразу идиоматично может быть сложно.


⁉️А выбор способа отвязки сводится к решению owner-команды со-зависимого сервиса (источника данных) о степени своего участия в проекте, обратно пропорциональной объёму совокупного тех. долга:
- готова вложится во избежание тех. долга - делаем красиво (1)
- готова удилить внимание и согласовать контракт - идем на компромисс (2)
- не готова помогать - используется синхронный вариант (3)

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