Как определить границы микросервиса: связность, зацепление и требования к системе

Если изменение одной скидки требует одновременно выпускать каталог, корзину, заказы и оплату, количество репозиториев ещё не делает систему независимой. Главный вопрос при выборе границы — какую связанную ответственность сервис сможет менять и обслуживать самостоятельно.

Универсального числа таблиц, классов или строк кода для микросервиса нет. Начните с предметной области и требований. Ниже — авторский разбор условного интернет-магазина: в нём покупатель собирает корзину, оформляет заказ, оплачивает покупку и получает доставку. Схема показывает ход архитектурного решения, а не единственную правильную декомпозицию любого магазина.

Не начинайте с перечня технических слоёв

Разделение на «сервис контроллеров», «сервис бизнес-логики» и «сервис базы» сохраняет зависимость каждого пользовательского действия от всех трёх частей. Паттерн Decompose by business capability предлагает другое основание — возможности бизнеса. В примерах Криса Ричардсона это управление каталогом, запасами, заказами и доставкой.

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

Microsoft описывает bounded context как явную границу модели. Обычно функциональность одного сервиса не должна смешивать несколько таких контекстов. Но контекст не является командой немедленно создать отдельный процесс: сначала выясняют модель, затем оценивают реализацию и эксплуатационные требования.

Составьте карту действий и правил

Авторское упражнение для магазина — выписать не сущности, а решения. Кто определяет доступность товара? Кто фиксирует состав и сумму подтверждённого заказа? Где принимается результат оплаты? Кто отвечает за изменение маршрута? К каждому решению добавьте данные, владельца правила и ситуации изменения.

Кандидат	Ответственность в нашем примере	Вопрос к границе
Каталог	Публикация описаний и характеристик для выбора	Нужно ли менять его при каждом новом правиле подтверждения заказа?
Заказ	Состав, согласованная сумма и допустимые переходы состояния	Какие изменения должны быть атомарными внутри этой модели?
Оплата	Взаимодействие с платёжным провайдером и состояние платежа	Как заказ узнаёт результат, не управляя внутренними таблицами оплаты?
Доставка	Варианты исполнения и отслеживание отправки	Что происходит при недоступности внешнего перевозчика?

Это предварительные кандидаты, а не готовый проект. Корзина может остаться модулем рядом с заказами, если отдельная эксплуатация не даёт пользы. Платёжную интеграцию можно сначала изолировать внутри приложения. Самостоятельное развёртывание должно решать конкретную проблему, иначе появляется дополнительная сеть без нужной автономии.

Высокая связность: вместе остаётся то, что меняется по одной причине

Связность означает содержательную близость обязанностей внутри компонента. Ричардсон применяет Common Closure Principle: части, меняющиеся по одной причине, полезно держать вместе. Это не совет собирать все функции со словом «клиент» в огромном сервисе, а проверка реальных правил и совместных изменений.

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

Microsoft предлагает рассматривать агрегаты как кандидатов: они выводятся из бизнес-требований, обладают функциональной связностью и определяют границу сохранения. При этом «каждый агрегат обязательно отдельный сервис» — слишком механическое правило. Итог может быть крупнее, если это упрощает целостность и работу команды.

Низкое зацепление: проверяйте зависимости, а не только наличие API

HTTP между частями не гарантирует слабую связь. Если оформление заказа требует цепочки мелких синхронных запросов, а изменение одного поля заставляет согласовывать выпуск всех участников, граница остаётся жёстко сцепленной.

У Microsoft среди критериев есть отсутствие чрезмерно разговорчивых вызовов и зависимостей, требующих совместного развёртывания. Авторская диагностика — нарисовать один пользовательский сценарий, посчитать переходы между владельцами и отметить места ожидания. Число переходов само по себе не норматив; важны причина и последствия каждой зависимости.

Для примера оплаты можно обсуждать контракт результата: идентификатор заказа, идентификатор платежа и согласованное состояние. Потребитель не должен читать внутренние таблицы платёжного компонента, чтобы догадаться, завершилась ли операция. Microsoft подчёркивает владение сервисом собственными данными и схемой; доступ другим частям предоставляется через определённые интерфейсы.

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

Нефункциональные требования способны изменить границу

После модели наложите требования доступности, масштабирования, безопасности, технологий и организации команд. По руководству Microsoft они могут привести как к разделению кандидата, так и к объединению нескольких кандидатов.

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

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

Проверьте вариант на изменениях и сбоях

Авторская проверка карты магазина состоит из трёх сценариев. Первый: появляется новое правило подтверждения заказа. Какие части меняются? Второй: платёжный провайдер недоступен. Может ли система объяснить покупателю состояние заказа? Третий: доставка меняет внешний формат. Нужно ли выпускать каталог?

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

Можно оформить короткую запись решения: ответственность; собственные данные; входные и выходные контракты; требования согласованности; команда; развёртывание; наблюдение; ожидаемая польза; причины пересмотра. Такой документ делает обсуждение предметным и помогает проверить первоначальные предположения после внедрения.

Когда разумнее сохранить более крупный компонент

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

Если маленькая команда выпускает приложение целиком, модель ещё нестабильна, а отдельное масштабирование не требуется, полезным результатом может стать модульная организация внутри одного приложения. Границы ответственности всё равно нужны; отдельная сеть — следующий обоснованный шаг.

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