В презе, которой - страшно сказать - больше шести лет, я ссылаюсь на статью Дэвида Парнаса On the Criteria To Be Used in Decomposing Systems into Modules. Статья, которая ровесник фильма "Крестный отец", песни Smoke on the Water группы Deep Purple и баскетбольного матча СССР - США ("За себя и за Сашку!"), рассказывает буквально о том, о чем написано в названии - о том, какие критерии нужно применять, чтобы декомпозировать систему на модули.
В качестве плюсов хорошо структурированной модульной системы в статье называются:
🔹 управляемость - отдельные команды могут работать над модулями независимо (с минимальными коммуникациями) и параллельно, время создания системы сокращается. Эта плюшка мало изменилась за больше чем полвека, туда же в копилку всякие API First, слабая связанность и прочие приколы "современности".
🔹 гибкость системы/ продукта - изменения одного модуля можно делать без изменения остальных. Аналогично, в современных условиях это свойство расширяется на процессы эксплуатации - когда система должна работать 24/7 и существовать кратно дольше срока своего создания, такая гибкость - единственный способ выживания продуктов и сервисов.
🔹 "понятность, осозноваемость" (дурацкий перевод термина comprehensibility) - систему легче изучить, изучая по одному модулю за раз. Сейчас это принято называть ограничением когнитивной нагрузки
Но ведь... микросервисы... это такое новое... никогда такого не было...🥺
В общем, статья тут, крайне рекомендую прочитать всем, кто явно или неявно решает архитектурные задачи, связанные с декомпозицией программных систем. Попозже, если интересно, сделаю краткий конспект