При разработке эффективного веб-приложения важно правильно настроить архитектуру программного обеспечения. Отличный способ создания поддерживаемого веб-приложения — это создание гибкой, расширяемой и адаптируемой архитектуры. Гексагональная архитектура — популярный архитектурный паттерн в разработке программного обеспечения. Этот стиль архитектуры способствует разделению задач, помещая логику на разные уровни приложения. Сегодня мы собираемся глубже погрузиться в гексагональный архитектурный паттерн и обсудить принципы, плюсы и минусы, варианты использования и многое другое.
Что такое шестиугольная архитектура?
Гексагональная архитектура, или архитектура портов и адаптеров, является результатом работы Алистера Кокберна. Это архитектурный шаблон, используемый для разработки программных приложений. В гексагональной архитектуре мы ставим наши входы и выходы на первый план. Это позволяет нам изолировать центральную логику приложения от внешнего мира. Поскольку наши входы и выходы находятся на грани, мы можем переключать их обработчики, не затрагивая наш основной код.
Гексагональная архитектура направлена на повышение ремонтопригодности наших веб-приложений, чтобы наш код потребовал меньше работы в целом. Шестиугольная архитектура представлена шестиугольником. Каждая из сторон шестиугольника представляет разные способы взаимодействия нашей системы с другими системами. Мы могли общаться, используя HTTP-запросы, REST API, SQL, другие шестиугольные архитектуры и т. Д. Каждый уровень шестиугольника не зависит от других слоев, поэтому мы можем вносить индивидуальные изменения, не затрагивая всю систему.
Давайте посмотрим, как может выглядеть шестиугольная архитектура:
Слой приложения представлен в виде шестиугольника. Внутри шестиугольника у нас есть объекты домена и варианты использования, которые с ними работают. Как видим, исходящих зависимостей нет. Все наши зависимости указывают на центр. Внутренняя часть шестиугольника или домена не зависит ни от чего, кроме самого себя. Это гарантирует, что бизнес-логика отделена от технических уровней. Это также гарантирует, что мы можем повторно использовать логику домена. Если мы изменим наш стек, это не повлияет на код домена. Ядро содержит основную бизнес-логику и бизнес-правила.
За пределами шестиугольника мы видим разные адаптеры, которые взаимодействуют с нашим приложением. Различные адаптеры будут взаимодействовать с разными аспектами приложения. Например, у нас может быть веб-адаптер, который взаимодействует с веб-браузером, некоторые адаптеры, которые взаимодействуют с внешними системами, и адаптер, который взаимодействует с базой данных. Адаптеры на левой стороне управляют нашим приложением, потому что они вызывают наше ядро приложения. Адаптеры с правой стороны управляются нашим приложением, потому что они вызываются ядром нашего приложения.
Адаптеры — это либо внешние API вашего приложения, либо клиенты других систем. Адаптеры используют порты для инициирования взаимодействия с приложением. Контроллер REST может быть примером адаптера. Ядро приложения предоставляет порты для связи с адаптерами. Порты позволяют нам подключать адаптеры к основному домену. Мы можем думать о портах как о независимых точках входа.
Примечание. Гексагональная архитектура не должна зависеть от какой-либо технической основы. Сюда входят внешние аннотации, такие как Java Persistence API (JPA) и Jackson.
Преимущества перед традиционной многоуровневой архитектурой
Гексагональная архитектура была отходом от традиционной многоуровневой архитектуры. Одним из основных отличий гексагональной архитектуры является возможность замены пользовательского интерфейса. Использование гексагональной архитектуры вместо многоуровневой дает множество преимуществ. Давайте посмотрим на некоторые плюсы, минусы и варианты использования:
Плюсы
- Ремонтопригодность: наши приложения обладают высокой ремонтопригодностью, поскольку изменения в одной области нашего приложения не влияют на другие области.
- Гибкость: мы можем легко переключаться между различными приложениями и можем добавлять новые адаптеры без изменения исходного кода.
- Простое тестирование: поскольку наш код отделен от внешних деталей реализации, мы можем тестировать изолированно.
- Агностик: поскольку приложение не зависит от внешних сервисов, мы можем разработать внутреннее ядро до создания внешних сервисов.
Минусы
- Развязка: на производительность нашего приложения могут повлиять промежуточные классы.
- Отладка: иногда бывает трудно понять и отладить адаптеры.
- Сложность: гексагональная архитектура иногда может сбивать с толку, потому что не всегда очевидно, что мы должны учитывать снаружи.
Сценарии использования
Вот несколько примеров использования гексагональной архитектуры:
- Банковское приложение, позволяющее отправлять деньги с одного счета на другой.
- Система, которая позволяет нам подавать заявку на получение кредита, проходить проверку и получать обновления при обновлении нашего приложения.
- Приложение лояльности, которое позволяет нам регистрировать клиентов и повышать или понижать их членство.
Принципы шестиугольной архитектуры
Теперь давайте взглянем на некоторые принципы, лежащие в основе гексагональной архитектуры.
Принцип единой ответственности
Принцип единой ответственности определяется как «компонент должен иметь только одну причину для изменения ». В отношении архитектуры это означает, что если у компонента есть только одна причина для изменения, нам не нужно беспокоиться об этом компоненте, если мы изменим программное обеспечение по какой-либо другой причине.
Инверсия зависимостей
Принцип инверсии зависимостей (DIP) позволяет нам инвертировать направление любой зависимости в нашей кодовой базе. Загвоздка в том, что мы можем инвертировать зависимости только тогда, когда у нас есть контроль над обеими сторонами зависимости. Итак, если у нас есть зависимость от сторонней библиотеки, мы не можем ее инвертировать, потому что мы не контролируем код библиотеки.
Давайте рассмотрим принцип инверсии зависимостей в действии. Допустим, мы хотим инвертировать зависимость между нашим кодом домена и нашим кодом сохранения состояния, чтобы наш код сохранения полагался на код домена. Мы будем использовать следующую структуру:
В приведенной выше структуре у нас есть служба на уровне домена, которая работает с репозиторием и сущностью на уровне сохраняемости. Мы можем создать интерфейс для репозитория на уровне домена и позволить репозиторию на уровне персистентности реализовать его. Это позволяет нам освободить логику нашей предметной области от зависимости от кода сохранения. Вот как бы это выглядело:
Изолируйте границы с помощью портов и адаптеров
Порты и адаптеры позволяют нам запускать наше приложение в полностью изолированном режиме. Гексагональная архитектура использует порты и адаптеры, чтобы проиллюстрировать связь между внутренней и внешней стороной. Порты — это границы нашего приложения. Есть два типа портов: первичный и вторичный.
Первичные порты или входящие порты — это начальные точки связи между внешним миром и ядром приложения. Первичные порты — это то, где запросы поступают в приложение. Вторичные порты или исходящие порты используются ядром приложения для восходящего потока данных к внешним службам.
Адаптеры служат реализацией наших портов. Есть два типа адаптеров: первичный и вторичный. Первичные адаптеры — это реализации первичных портов. Они не зависят от ядра приложения. Вторичные адаптеры — это реализации вторичных портов. Они также не зависят от ядра приложения.
Пример шестиугольной архитектуры
Ранее в статье мы перечислили несколько вариантов использования гексагональной архитектуры. Теперь мы начнем работать с одним из этих вариантов использования в коротком руководстве. Мы рассмотрим пример использования приложения, которое позволяет нам отправлять деньги с одного счета на другой. Давайте посмотрим на тизер кода, который мы напишем для создания SendMoneyServiceкласса:
package buckpal.account.application.service;@RequiredArgsConstructor@Transactionalpublic class SendMoneyService implements SendMoneyUseCase {private final LoadAccountPort loadAccountPort;private final AccountLock accountLock;private final UpdateAccountStatePort updateAccountStatePort;@Overridepublic boolean sendMoney(SendMoneyCommand command) {// TODO: validate business rules// TODO: manipulate model state// TODO: return output}}
Что учить дальше
Поздравляем, вы сделали первый шаг к использованию шестиугольной архитектуры! Шаблон проектирования программного обеспечения с гексагональной архитектурой создает уровень абстракции, который изолирует ядро приложения от внешних инструментов и технологий. Это популярный архитектурный стиль в разработке программного обеспечения. Вот некоторые рекомендуемые темы для дальнейшего изучения:
- HTML
- Весенний ботинок
- SQL
- API
