Всегда приятно, когда твои материалы упоминают в профильных статьях и постах. Александр Межов в своём канале в ходе рассуждений над одной из тем рекомендует мой принцип каскадного снижения связанности: https://t.me/arch_and_dev/83 😊 Позволю себе несколько комментариев к контексту рекомендации и к исходному посту в целом. Сам исходный пост является комментарием к статье "Microservices antipatterns and pitfalls" Марка Ричардса, то есть у меня будут комментарии на комментарий 😂 Речь идёт о холиварной теме границ микросервиса и его размера. В неблагодарном деле определения этих параметров Александр и упоминает мою статью: При этом важно принимать во внимание то, насколько прочны логические связи между перечисленными функциями сервиса, насколько они логически согласованы и сочетаются друг с другом. Если изъянов нет, то процесс декомпозиции выполнен успешно и нет причин для беспокойства. (По этой теме рекомендую обратить внимание на "Принцип каскадного снижения связанности", сформулированный Русланом Сафиным.) 💡 Интересная мысль! Конкретно в разрезе определения правильности оптимальности декомпозиции микросервисов, о принципе снижения связанности я ещё не думал 🙂 Но в целом — да, в конечном счёте именно внешние проявления существования микросервиса (его использование другими и его собственные зависимости от других) определяют и характеризуют все его смыслы и качества, в том числе и эффективность его границ. Без внешних проявлений микросервис бессмыслен (микросервис не монолит — как вещь в себе, он невозможен). В целом, у меня есть отдельная статья и доклад про гранулярность микросервисов. В них я тоже упоминаю связанность и связность, но до идей отслеживания динамической связанности я тогда ещё не дошел :) Или стоит более пристально взглянуть на существующие потоки данных и выявить изъяны? 🤨 Возможно, те данные, которые находятся в стороннем сервисе, должны находиться в нашем. Возможно, стороннему сервису достаточно иметь реплику какой-то части данных нашего сервиса. Конечно, тут могут быть разные варианты, но это отличный способ посмотреть на существующее решение под другим углом. И вновь отличный комментарий! Появление "микросервисных монолитов" зачастую оправдывают транзакционностью обработки данных, которую никто не хочет делать распределённой. При этом, зачастую не видят проблем в самом способе получения, хранения и обработки данных — говоря об архитектуре микросервисов, иногда забывают об архитектуре принадлежности данных, их потоков и их разделения. На эту тему могу так же посоветовать статью: Управление мастер-данными в микросервисной архитектуре 3️⃣Степень общительности сервисов Насколько много внешних сервисов задействованы при выполнении операций целевого? Это в какой-то степени допустимо для API-шлюзов и workflow-оркестраторов, но в иных случаях это "черная метка". Каждое обращение к внешнему сервису снижает пропускную способность и надёжность. Вот здесь как раз принцип каскадного снижения связанности должен помочь в полной мере! :) Можно даже поэкспериментировать с различного рода архитектурами на бумаге в PlantUML и посчитать их метрики автоматом. 4️⃣Соответствие целям бизнеса Для чего делается сервис? Какую проблему бизнеса он решает? Ответы на эти вопросы могут существенным образом повлиять на итоговое решение. 👔 Например, если в основе требований бизнеса — уменьшение TTM (Time-To-Market), то будет стремление к множеству мелких сервисов; если повышение надёжности, то будет стремление к укрупнению сервисов. А вот с последним доводом я скорее не соглашусь. Всё же чем крупнее сервис, тем больше шансов, что он упадёт, будет тормозить или в нём будут баги. Про проектирование отказоустойчивости у меня естественно тоже есть статья 😅 Получился не совсем самостоятельный пост, а больше обсуждение или даже кусочек асинхронной беседы, вынесенный на публике. Но, имхо, как раз в беседах и рождаются новые идеи и развиваются старые! И кажется будет не лишним в лишний раз (🙂) собрать ссылочки на статьи по теме. ☀️