Продолжаю обзор "Микросервисов" Ричардсона. Сегодня вторая глава, дающая уже более интересный материал, чем просто перечисление паттернов.

Чтобы разобраться с тем, как проектировать и строить микросервисную архитектуру, нужно сначала дать определение архитектуре программного обеспечения как таковой. Ричардсон приводит определение Лена Басса:
"Программная архитектура вычислительной системы - это набор структур, необходимых для её обсуждения и состоящих из программных элементов, связей между ними и свойств, присущих этим элементам и связям".

Модель представлений архитектуры вида 4+1
Архитектура 4+1 - это универсальный способ описания архитектуры любого приложения, предложенный Филиппом Кратченом, который состоит из четырёх разных представлений архитектуры ПО, где каждое описывает определённый аспект и состоит из определённого набора элементов и связей между ними:
* Логическое представление - модули, создаваемые разработчиками. Например, в ООП языках это классы и пакеты. Связи между ними - отношения между классами, включая наследование и зависимости.
* Представление реализации - результат работы системы сборки. Для компилируемых языков, например, это исполняемый файл, с соответствующими зависимостями, представленными в компилируемом виде.
* Представление процесса - компоненты на этапе выполнения. Каждый элемент является процессом, а отношения между ними - межпроцессорное взаимодействие.
* Развертывание - то, как процессы распределяются по устройствам. Элементами тут выступают сервера и процессы. Связи между ними - сеть.
+1 - это сценарии, определяющие связи и то, как представление обрабатывает запрос.

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

Есть разные стили архитектуры.

Классический - многоуровневый стиль, в котором можно выделить наиболее частый - трёхуровневый:
* уровень представления - код, реализующий пользовательский интерфейс или внешние API
* уровень бизнес-логики
* уровень хранения данных - реализация взаимодействия с базой данных
Недостатки многоуровневой архитектуры:
* Подразумевается единый уровень представления и не учитывается, что клиентов может быть несколько
* Единый уровень хранения данных не подразумевает, что будет работа с более чем одной базой
* Уровень бизнес-логики зависит от уровня хранения данных - в теории эта зависимость не позволяет тестировать бизнес-логику отдельно от БД

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