Продолжая тему разберем теорию на вымышленном примере.

Дано:
Монолитное приложение, с историей заказов, логикой чекаута (офорление заказа) и т.д.

Задача:
Реализовать в сервисе систему лояльности с начислением бонусов клиенту:
- на каждый заказ по прогрессивной шкале начисляются бонусы (статус клиента)
- каждый месяц шкала обнуляется (статус сбрасывается)
- бонусы можно списывать при оформлении заказа.

0️⃣Монолитная реализация
Дефолтный паттерн делания фичи в монолите - внедрить в чекаут новый функционал:
- добавляем логику начисления бонусов с заказа
- шкалу определяем, обращаясь к истории заказов

1️⃣Идиоматичная реализация
Данные о заказах должны прилетать асинхронно из сервиса "Чекаута" (со-зависимый сервис) сразу после оформления заказа. Сервис лояльности (зависимый) накапливает данные о сумме заказа каждого клиента за месяц. Таким образом денормализованные данные минимальные данные о заказах клиента в лояльности являются проекцией данных на ограниченный контекст "лояльности".

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

2️⃣Компромиссная реализация
На базе монолитного приложения (без выноса чекаута) запускаем топик с информацией об оформленном заказе (пунктир). Согласовываем с owner-командой чекаута: количество противоречий с идиоматичной версией контракта должно быть минимизировано.
После реализации топика (сделать его может любая из команд), продюсер в монолите передается на "баланс" команде чекаута.

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

3️⃣Синхронная реализация
Для расчета статуса клиента сервис лояльности ходит в БД монолита (может быть эндпойнт), и на базе не своих данных производит необходимые вычисления.

Сильная связность не позволяет назвать сервис автономным.

💡Но даже такой вариант - это уже первый шаг к автономности. Но дальше нужно двигаться 3, 2, 1.