По какому принципу правильнее проводить границы между сервисами?

Ограниченный контекст — область, внутри которой термины имеют одно значение и одну модель. «Заказ» при оформлении — корзина с промокодами и доставкой, на складе — позиции с весом и местом хранения, в бухгалтерии — документ с НДС. Попытка сделать один общий класс Order для всех даёт объект с десятками полей, который меняется по любой причине и связывает всех.

Почему не по сущностям и не по слоям. «Сервис пользователей», к которому ходит каждый, — центральная зависимость и узкое место. Нарезка по слоям (API-сервис, сервис логики, сервис данных) превращает каждый запрос в цепочку синхронных вызовов, где отказ любого звена — отказ всего.

Критерии хорошей границы:

• основные сценарии выполняются внутри одного сервиса;
• сервис владеет своими данными, другим их не отдают напрямую;
• изменения обычно затрагивают один сервис;
• граница совпадает с зоной ответственности команды;
• агрегат (единица согласованности, например заказ с позициями) не разрезан между сервисами — одна транзакция меняет один агрегат.

Как искать: event storming — разложить процесс на бизнес-события и найти, где меняется язык и ответственность; смотреть на частоту совместных изменений в коде.

Признаки ошибки: синхронные цепочки на каждый запрос, распределённые транзакции, «общая библиотека моделей», изменения в нескольких репозиториях ради одной фичи.