Рекомендую к прочтению книжку Распределенные системы. Паттерны проектирования. Издательство Питер, 2019 - тот редкий случай, когда для чтения перевода не нужно иметь под рукой англоязычный оригинал. Книжка, безусловно, про паттерны, но не только про паттерны. Так, например, один из вопросов, на которые она дает ответ - как быть с повторно-используемыми (reusable) компонентами в микросервисной архитектуре

Рекомендую к прочтению книжку Распределенные системы. Паттерны проектирования. Издательство Питер, 2019 - тот редкий случай, когда для чтения перевода не нужно иметь под рукой англоязычный оригинал. Книжка, безусловно, про паттерны, но не только про паттерны. Так, например, один из вопросов, на которые она дает ответ - как быть с повторно-используемыми (reusable) компонентами в микросервисной архитектуре

В отличии от сервиса в сервис-ориентированной архитектуре, которые изначально рассматривался как компонент, разработанный для повторного использования, микросервис таковым не является. Скорее наоборот, мы реализуем в микросервисе некий частный случай, функционал, востребованный иногда или возможно востребованный, например, при тестировании гипотез или функции необходимые лишь части клиентов и т.п.
Где же в этом случае реализовывать многократно используемые функции? В монолите такие функции реализуются в виде библиотек, принося с одной стороны несомненную пользу, а с другой – ад зависимостей. Брендан Бёрнс, автор книжки про паттерны проектирования распределенных систем, рекомендует реализовывать такой функционал в виде отдельных контейнеров. Нужен вам reusable функционал – добавляете в свой pod соответствующий контейнер и вызываете его из основного процесса внутри вашего микросервиса

Ян Шарп произнес эти слова в 1969 году на конференции NATO Conference on Software Engineering Techniques:

Есть некое дополнение к программированию, и его надо вытащить на свет. Это программная архитектура. Архитектура и проектирование(дизайн, примечание моё) — не одно и то же. В качестве примера рассмотрим ОС/360. Части ОС/360 запрограммированы чрезвычайно хорошо, в них использовано множество удачных идей и методов. Причина, по которой операционная система оказалась бесформенной кучей программ, состоит в том, что у нее не было архитектора ... Обычно спецификации программного обеспечения рассматриваются как функциональные: мы рассуждаем лишь о том, что программа должна делать. Но любой, кто отвечает за реализацию программного обеспечения, должен задуматься о большем. Ему необходимо выстроить проект — форму; в рамках которой будут творить программисты или инженеры. Ни один инженер либо программист, ни один инструмент программирования не поможет ни нам, ни софтверному бизнесу компенсировать недостатки проекта. Контроль, управление, обучение и другие вещи, о которых мы говорим, очень важны, но специалисты по реализации должны понимать замысел архитектора (конец цитаты, см. https://www.osp.ru/os/2006/03/1156577/)

Очевидно, что архитектура, в первую очередь, это история о замыслах, удачных более или менее, подходящих задаче или нет, сформулированных четко или расплывчато, воплощенных в софте или утраченных еще на ранних стадиях существования продукта