Я определяю границы сервисов по тому, кто меняет правило

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

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

Почему названия отделов сбивают с толку

Допустим, есть «отдел продаж», «финансы» и «поддержка». Кажется естественным сразу сделать три отдельных блока. Но правило о лимите отсрочки оплаты может касаться и сделки, и счёта, и обращения клиента. Если каждая команда хранит свою версию правила, система начинает спорить сама с собой.

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

Что я ищу перед разделением

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

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

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

Граница — это обещание, а не стена

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

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

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

Не дробите систему ради красивой схемы

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

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

Проверьте границу на изменении

Самая честная проверка архитектуры — не диаграмма, а будущая правка. Возьмите вероятное изменение: новый тип договора, другой порядок согласования, дополнительный канал продаж. Затем спросите: какие части затронуты, кто должен принять решение, можно ли вернуть прежнее состояние и где будет история изменения?

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

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

С чего начать

1. Выберите одно правило с заметной ценой ошибки.
2. Запишите, кто владеет его смыслом и какие данные нужны для решения.
3. Определите, какой итог получают другие части системы.
4. Проверьте на следующем изменении, не приходится ли им знать лишние детали.
5. Только после этого решайте, нужен ли отдельный сервис или достаточно внутреннего модуля.

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