Микросервисы по зависимости: Новая причина для деления архитектуры

Бывает такое, что надо добавить крупный набор фич, но которые могли бы условно быть даже отдельным \"мини-продуктом\", который интегрируется с вашим

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

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

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

Он может также использовать прямые запросы в основную БД (чтобы не плодить дополнительные ручки), НО только к таблицам, из которыз он читает. Все таблицы, в которые он пишет, должны быть уникальны для этого сервиса.

Также, важно, чтобы основная кодовая база никак не менялась под этот сервис, максимум, добавлялись новые фичи, которые могут быть интересны этому мини-продукту

То есть, оснвоной продукт не должен зависеть от мини-продукта, но при этом мини-продукт будет зависеть от основного

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

Можно было бы назвать это \"ответственностью\", но важнее тут кто от кого зависит и придерживаться этой зависимости