Search
Write a publication
Pull to refresh

Comments 2

Спасибо за статью! Понимаю, что она сосредоточена именно на применении механизма очередей, но вот история с тем, что от монолита отпиливается по одному handler-y, имеет риск с другой стороны.

Кажется, что здесь важно иметь четкое архитектурное правило последующего размещения этих ручек по сервисам. Ведь это будет долгий процесс. И за время работы над ним может не просто что-то забыться - команда может поменяться. И как бы не получилось так, что ручки в итоге начнут переноситься по сервисам не особенно корректно. Как следствие, микросервисы превратятся в Service Mess, если можно так выразиться.

Поэтому упускать этот аспект, говоря о распиле монолитов, кажется рискованным.

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

Sign up to leave a comment.