Интересно поговорить не столько о теории (хотя там много подходов и книг), сколько о практике.
Когда мы начинаем проектировать новый продукт, у нас одна картина мира. Продакты и бизнес-аналитики рассказывают нам о продукте и требованиях. Мы выделяем поддомены, проектируем модели, понимаем, где будет логично провести между ними границы, уточняем нефункциональные требования и на основании полученной информации проектируем стартовый набор микросервисов.
Время идет, появляются новые микросервисы для новых фичей, старые микросервисы тоже активно развиваются, и спустя год или два может оказаться, что кто-то из первых микросервисов стал уже больше напоминать отдельный монолит. А некоторые изначально разделенные сервисы сильно связались следующими фичами, и сервис Б практически на каждый пользовательский запрос вынужден ходить по REST/gRPC в сервис А.
Если есть циклическая зависимость, то это признак, что стоит рассмотреть объединение сервисов. Если зависимость не циклическая, то вроде и ничего страшного, а с другой стороны - разные ли это контексты, если сервис Б без сервиса А практически ни одного запроса своего API обработать не может?
Необходимость в рефакторинге можно заметить относительно вовремя, когда стало "немного некомфортно" при реализации новой фичи, но техдолг еще не большой. Но не всегда есть бизнесовая возможность заняться этим сразу, как заметили. Исходя из моего опыта, такие работы лучше аккуратно увязывать вместе с новыми фичами этих сервисов, чтобы и бизнесу польза и техдолг архитектурный не копился.
Пара примеров, с чем сталкивалась:
🩷Отправка уведомлений была реализована в бизнесовом сервисе. Когда уведомления понадобились во втором сервисе, сразу заметили и выделили отдельный сервис уведомлений.
Сейчас кажется это классика, на моках сисдиза вечно рисуют сразу сервис уведомлений отдельный, но тогда столько материалов не было, проходили на практике.
🩷Первый сервис продукта назвали
core. В нем был расчет основного отчета, с которого начинался продукт, а вокруг вспомогательные сервисы, которые готовили данные для core. Также в core были справочники и всякие пользовательские настройки. С развитием продукта появлялись новые микросервисы под новые фичи, но все они для некоторых задач ходили в core за пользовательскими настройками. При этом в core оставались и свои фичи вокруг основного отчета. На третьем фичевом микросервисе, который собрался в core, мы разделили первоначальный core на собственно core с пользовательскими настройками и справочниками, а расчет основного отчета вынесли в отдельный фичевый микросервис.С одной стороны кажется, что тут изначально был просчет, почему пользовательские настройки сразу не вынесли? Потому что при начальном проектировании не было очевидно, что эти настройки будут актуальны не только для фич этого микросервиса, но и для других, новых. Плюс важный момент, что продукт развивался из MVP, который нужно было сделать быстро и качественно под текущие задачи, чтобы запуститься, а затем развивать и улучшать.
Случалось ли, что делая новую фичу, вы ловили себя на мысли: кажется, этот микросервис "набух" и его пора разделять?
Инициировалось ли у вас на проектах изменение границ микросервисов? Если да, то кто выносил такой вопрос на обсуждение: разработчики, системные аналитики или архитекторы?