🦾 IT-Качалка Давида Шекунца 💪
2024-02-15 12:00
Бывает такое, что надо добавить крупный набор фич, но которые могли бы условно быть даже отдельным \"мини-продуктом\", который интегрируется с вашимНапример, клиенты вашей системы используют ее для своих клиентов и захотели, чтобы вы добавили возможность тарифицировать их клиентовПо факту, это не является частью вашей платформы и может быть реализовано через ваш внешний API, как отдельное приложениеНо по тем или иным причинам, вы хотите иметь возможность переиспользовать какую-то часть инфры и кодовой базы, поэтому данный мини-продукт имеет смысл делать как микросервис, но в рамках вашего монорепозиторияОн может также использовать прямые запросы в основную БД (чтобы не плодить дополнительные ручки), НО только к таблицам, из которыз он читает. Все таблицы, в которые он пишет, должны быть уникальны для этого сервиса.Также, важно, чтобы основная кодовая база никак не менялась под этот сервис, максимум, добавлялись новые фичи, которые могут быть интересны этому мини-продуктуТо есть, оснвоной продукт не должен зависеть от мини-продукта, но при этом мини-продукт будет зависеть от основногоИ вот в такой ситуации, выделять его в микросервис, отличная идея, потому что тогда кодовая база основного продукта будет в безопасности + уставшему разработчику будет нарушить эту зависимость при написании кодаМожно было бы назвать это \"ответственностью\", но важнее тут кто от кого зависит и придерживаться этой зависимости