Архитектура приложения
Общая структура, состоящая из отдельных частей и зависимостей между ними.
- масштабируемость
- надежность
- безопасность
- Логическое представление — программные элементы, создаваемые разработчиками. В объектно-ориентированных языках это классы и пакеты. Связи между ними соответствуют отношениям между классами и пакетами, включая наследование, взаимосвязи и зависимости.
- Представление реализации — результат работы системы сборки. Это представление состоит из модулей, представляющих упакованный код, и компонентов, которые являются исполняемыми или развертываемыми единицами и содержат один или несколько модулей.
- Представление процесса — компоненты на этапе выполнения. Каждый элемент является процессом, а отношения между процессами представляют межпроцессное взаимодействие.
- Развертывание — то, как процессы распределяются по устройствам. Элементы в этом представлении состоят из серверов (физических или виртуальных) и процессов. Связи между серверами представляют сеть. Это представление также описывает отношение между процессами и устройствами.
Архитектура монолита, к чему привыкло большинство разработчиков
- уровень представления — содержит код, реализующий пользовательский интерфейс или внешние API;
- уровень бизнес-логики — содержит бизнес-логику;
- уровень хранения данных — реализует логику взаимодействия с базой данных.
Шестигранная архитектура — это альтернатива многоуровневому стилю проектирования. Она организует логическое представление таким образом, что бизнес-логика оказывается в центре
У бизнес-логики есть один или несколько портов. **Порт** определяет набор операций и то, как и в чем бизнес-логика взаимодействует с внешним кодом. Порт часто является интерфейсом. Существует два вида портов: входящие и исходящие.
_Входящий порт_ — это API, выставляемый наружу бизнес-логикой и доступный для вызова внешними приложениями.
_Исходящий порт_ — это то, как бизнес-логика обращается к внешним системам.
Вокруг бизнес-логики размещаются адаптеры. Как и порты, они бывают двух типов: входящие и исходящие.
_Входящий адаптер_ обрабатывает запросы из внешнего мира, обращаясь к входящему порту.
Еще один пример — клиентский брокер сообщений, который на них подписывается. Несколько входящих адаптеров могут обращаться к одному и тому же входящему порту.
_Исходящий адаптер_ реализует исходящий порт и обрабатывает запросы бизнес-логики, обращаясь к внешнему приложению или сервису.
Сервис
Сервис — это автономный, независимо развертываемый программный компонент, который реализует определенные функции. Через собственный API сервис предоставляет доступ к своим функциям.
- Команда - такая как createOrder(), выполняет действия и обновляет данные.
- Запрос - такой как findOrderById(), извлекает данные.
- Сервис - публикует события, например OrderCreated, которые потребляются его клиентами.
_API сервиса инкапсулирует его внутреннюю реализацию. В отличие от монолита этот подход не позволяет разработчику писать код, минующий API. Благодаря этому микросервисная архитектура обеспечивает модульность приложения._
Каждый микросервис обладает собственной архитектурой и иногда отдельным стеком технологий. Но обычно сервисы имеют шестигранную архитектуру. Их API реализуются адаптерами, которые взаимодействуют с бизнес-логикой приложения. Бизнес-логика вызывается адаптером операций, а события, которые она генерирует, публикуются адаптером событий.
Размер сервиса обычно не имеет значения
Одна из проблем термина «микросервис» — то, что в глаза сразу бросается «микро». В реальности размер не является полезной характеристикой. Определение хорошо спроектированного сервиса лучше связать с возможностью разрабатывать его в небольшой команде, как можно быстрее и минимально взаимодействуя с другими командами. Теоретически команда должна отвечать только за один сервис, чтобы тот и в самом деле был микроскопическим. Если же сервис требует большой команды разработчиков или слишком много времени на тестирование, его, как и саму команду, имеет смысл разделить на части.