Шестиугольная архитектура

Шаблоны проектирования

1 Обзор

Шестиугольная архитектура, также известная как порты и адаптеры, представляет собойAlistair Cockburnпредложил в 2005 году.

намерение

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.

Позволяет приложениям в равной степени управляться пользователями, программами, автоматизированными тестами или пакетными сценариями, а также разрабатываться и тестироваться отдельно от конечного устройства среды выполнения и базы данных.

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

  1. Hexagonal architecture

  2. Видео Алистера

  3. Hexagonal Architecture: three principles and an implementation example

мотивация

Почему появляется шестиугольная архитектура?

Одним из самых больших недостатков программных приложений на протяжении многих лет было проникновение бизнес-логики в код пользовательского интерфейса. В связи с этим возникает тройная проблема:

  1. Во-первых, систему нельзя полностью протестировать с помощью набора автоматизированных тестов, потому что части логики, которые необходимо протестировать, зависят от часто меняющихся визуальных деталей, таких как размеры полей и положения кнопок.

  2. Точно по тем же причинам невозможно перейти от системы, управляемой человеком, к системе пакетного запуска.

  3. По той же причине, когда программа становится все более связанной, трудно или невозможно допустить, чтобы эта программа управлялась другой программой.

Опробованное во многих организациях решение состоит в том, чтобы создать новый слой в архитектуре и гарантировать, что на этот раз он работает.Не размещать бизнес-логику на новом уровнесередина. Однако, не имея механизма для обнаружения нарушения этого обещания, организация обнаружила, что через несколько лет новый уровень был загроможден бизнес-логикой, и вновь всплыла на поверхность старая проблема.

Мы знаем, что компьютер и периферийные устройства взаимодействуют с драйвером (адаптером) через порт, и нужен только соответствующий драйвер, порт может взаимодействовать с разными устройствами. Шестиугольная архитектура фокусируется на разнице между «внешним» и «внутренним».Внутренняя бизнес-логика (приложение) полностью изолирована от периферийных устройств (приложение, веб-сайт, база данных и т. д.) и взаимодействует только через адаптер.

2. Архитектурные идеи

Шестиугольная архитектура основана на трех принципах и приемах:

  • Explicitly separate Application, Domain, and Infrastructure
  • Dependencies are going from Application and Infrastructure to the Domain
  • We isolate the boundaries by using Ports and Adapters
  1. Четкое различие между тремя уровнями приложения, домена и инфраструктуры
  2. Зависимости от приложения и инфраструктуры к домену
  3. Используйте порты и адаптеры, чтобы изолировать их границы

Первый принцип: многослойность

Сторона приложения (приложение): этоПользовательили внешняя программас приложениемпроцедуравзаимодействоватьбоковая сторона. Здесь есть HTTP-маршрутизация API и сериализация JSON, что несколько похоже на уровень контроллера MVC.

Домен (Domain): Та часть, которая изолирована от левого и правого концов, содержит весь код, задействующий и реализующий бизнес-логику.

Инфраструктура: здесь мы можем узнать, что нужно вашему приложению и какую работу оно может выполнить. Он содержит основные детали инфраструктуры, такие как код, взаимодействующий с базой данных, вызовы файловой системы или код, обрабатывающий вызовы HTTP к другим приложениям, от которых вы зависите.

Второй принцип: зависимости входят в домен

Проще говоря,Все зависит от Домена, а Домен ни от чего не зависит.. Алистер Кокберн настаивает на разделении внутреннего и внешнего, что более важно.заявлениеа такжев основном построитьРазличия носят более структурный характер и касаются исходной проблемы.

Третий принцип: граница и изоляция интерфейса

Таким образом, код приложения определяется бизнес-кодом.интерфейс(IRequestVerses здесь) для управления бизнес-кодом. Бизнес-код управляет инфраструктурой через интерфейсы, также определенные в бизнес-коде (IObtainPoems). Эти интерфейсы действуют как явный изолятор между внутренней и внешней частью.

Проще говоря, и приложение, и инфраструктура напрямую управляются интерфейсом, предоставляемым бизнес-кодом, и нам не нужно обращать внимание на то, как реализован бизнес-код.

Для более глубокого понимания трех правил, пожалуйста, обратитесь к:Hexagonal Architecture: three principles and an implementation example

3. Metaphor

Думайте об этом архитектурном шаблоне как о адаптере порта или шестиугольнике.

端口适配器

六边形

Что делает адаптер

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

Port

Для программных систем воплощением протокола порта на порту является API, то есть интерфейс, предоставляемый бизнес-системой, и порт может иметь несколько адаптеров. Например, система обеспечивает отображение информации о продукте. В настоящее время информация может потребоваться для предоставления информации о продукте в приложении, Интернете или в качестве удаленной службы. В настоящее время приложение предоставляет интерфейс запроса и возвращает объект. преобразование его в формат json приложения, веб-сайта или удаленной службы выполняется адаптером.

4. Hexagonal Architecture Example

Пример кода:Hexagonal Architecture Example

结构图

Резюме и ссылки

резюме

Большинство современных шаблонов проектирования являются шаблонами MVC. Уровень приложения, бизнес-уровень и уровень сохраняемости действительно просты в использовании. Однако, когда проект постепенно повторяется, некоторые бизнес-коды неоднозначны для слоев, и код может быть только в новый.Однако недостатки постепенно становятся все более и более очевидными, а связь между модулями постепенно увеличивается, что усложняет сопровождение кода и итерацию. В настоящее время нам нужна более четкая и простая архитектура для разработки. В дополнение к гексагональной архитектуре существует также Чистая архитектура. Заинтересованные друзья могут узнать сами.

Ссылки и рекомендуемая литература