Луковая архитектура по сравнению с шестиугольной

Question

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

Каковы различия между ними, если таковые имеются?

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

Каковы преимущества использования одного над другим и почему вы бы его использовали? когда его использовать?

Спасибо

Answer 1

Каковы различия между ними, если таковые имеются?

Лук: Существуют слои с зависимостями, всегда указывающими внутрь, т. Е. Слой может использовать любойслоев внутри него.Внутренний слой - это Модель предметной области, а внешний - инфраструктура, но число слоев между ними может варьироваться.

Гексагональная (это альтернативное название для исходного названия «Порты и адаптеры»):Там нет слоев.У вас есть приложение, порты и адаптеры.Порты принадлежат приложению, они являются API / SPI приложения.Адаптеры находятся за пределами приложения, и каждый из них зависит от порта приложения.

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

Реализация гексагонального права должна отделять адаптеры друг от друга, и каждый адаптер должен зависеть только от порта, который он использует / реализует (в зависимости от того, является ли порт драйверным или управляемым).

Другое отличие состоит в том, что шестиугольник ничего не говорит о структуре внутренней части шестиугольника (приложения).

Каковы преимущества использования одного над другим?

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

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

Почему вы используете его?когда его использовать?

Смысл использования любого из них заключается в том, что вы сосредотачиваетесь на реальной проблеме, которую пытаетесь решить, не используя какие-либо технологии или рамки.Приложение не зависит от технологий, и его легко перенести с одного фреймворка на другой.Из-за этого их обоих называют «чистыми» архитектурами.В ядре приложения нет кода платформы, аннотаций и т. Д.

Итак ... Зачем их использовать?

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

Когда их использовать?

Я бы лучше сказал, когда их не использовать.Если приложение, которое вы разрабатываете, не является сложным, например, это просто CRUD, возможно, оно не заслуживает их использования.

Лично мне больше нравятся "Порты и адаптеры", чем другие.

Надеюсь, что мое объяснение помогло.

Answer 2

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

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

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

Лук, шестиугольник, а также порты и адаптеры - фактически разные названия для одной и той же концептуальной архитектуры.

У Марка Симана есть отличный пост, который помогает прояснить, как различия, если таковые имеются, являются маргинальными и семантическими: Слои, Лук, Порты, Адаптеры: все это одно и то же

Answer 3

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

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

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

---

РЕДАКТИРОВАТЬ: я понимаю, что формулировка, что "архитектура лук рассматривает UI и доступ к данным, является частью одного уровня" может бытьинтерпретируется иначе, чем предполагалось.Дело в том, что в луковой архитектуре пользовательский интерфейс и функциональные возможности доступа к данным не находятся в иерархической взаимосвязи, как в случае многоуровневой архитектуры.