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

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

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

Ну, и конечно, вторая проблема: "ответственность" – очень субъективное понятие. Спроси в средней+ системе нескольких человек: "какие ответственности вы бы выделили?" – вариант каждого будет на 50% отличаться от другого. А повышение градума "субъективности" – путь бесконечных ошибок.

И любой человек, который делил микросервисы по ответственности в среднем+ проекте в итоге сталкивался, что они все вызывают друг друга миллионы раз и создают дедлупы

. А как правильно делить

Для начала определимся: "микросервис" содержит полностью отдельную кодовую базу и ресурсы и общается используя межсервисный транспорт, а "модуль" (модульного монолита) переиспользует кодовую базу и ресурсы другого модуля и может напрямую вызывать код соседнего модуля (без транспорта), но существует как отдельное приложение

Вот эту "примунную ответственность" разработчиком можно назвать "искуственной ответственностью", а нам нужно ориентироваться на "натуральную ответственность" и вот вам чеклист примеров этой "натруальной ответственности":

. Отдельная команда

Если есть две команды людей, который должны решать независимые части системы и не коммуницируют на постоянной основе (weekly, daily, свой менеджмент и т.д.), лучше чтобы каждые делали свой набор микросервисов / модулей и договаривались про API.

Даже общие библиотеки это опасно (должен быть 1 конкретный mainteiner этой либы), потому что любое вмешательство в код со стороны разраба из сторонней команды очень плохо контролируется и может деградировать пол системы

. Безопасность

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

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

(продолжение ниже)

. Геозависимость

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

Тоже самое, если вам нужно разместить какой-то сервис только в рамках одного из контуров (например только RU или EU), тогда вы можете сделать отдельный модуль чисто под этот контур.

. Stateful

Например, вам нужно держать открытые Web Socket или TCP соединения, при этом вы хотите как можно реже редеплоить и вообще трогать это приложение для максимального uptime, тогда вы выделяете отдельный микросервис / модуль, который будет хранить состояние (сокет) и общаетесь с ним через транспорт

. Отдельный набор фич

Вашим партнерам нужна урезанная / другая вариация вашего основного API, тогда вы создаете отдельный модуль, в котором выдаете наружу только то, что нужно + подменяете способ аутентификации (например, на oAuth) и т.д.

. Выделенные ресурсы

Ваше приложение требует большой работы с файловой системы, или, например, это сжатие картинок, или обработка потокового видео, или CPU-intensive рассчет, короче, что-то что требует особого ресурса. Тогда вы выделяете микросервис / модуль и деплоете его на тачках с нужными ресурсами.

. Мешает окружающим

Какая-то ручка особенно нагруженная (например, вы собираете каждый клик с бразуера клиента) и она генерирует слишком много трафика, обработка которого мешает обработки оставшихся запросов.

Тогда вы можете прям вот этот кусочек выделить в отдельный модуль / микросервис и задеплоить его на отдельной тачке.

. Независимость деплоя

Когда мы хотим, чтобы разные сервисы деплоились независимо друг от друга (например, чтобы редеплой неафектил приложения, код которых не был изменен в PR)

Тогда можно выделить модуль (у модулей свои независимые Docker image, поэтому после сборки можно проверять изменился ли hash чтобы принимать решение о редеплое) или микросервис

. Независимость бизнес-логики

Вот это САМЫЙ сложный аспект, потому что независимость одного микросервиса от другого – это часто временное понятие (помним, что требования всегда меняются), но если один модуль, по-настоящему способен оперировать независимо от другого (например, система рассчета вознаграждений и система аутентификации), тогда это претендент на выделение в микросервис

НО советую это делать вторым шагом, после того, как вы поняли, что эти модули по-настоящему стали независимыми друг от друга и для удобства дальнейшей разработки вы хотите выделить кодовые базы

ЕЩЕ РАЗ, только время покажет реальную независимость кодовых баз

Итоги

Уверен, что упустил и другие здоровые причины деления приложений на модули и микросервисы, так что пишите в комменты