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

Ответ 1

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

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

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

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

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

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

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

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

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

Зачем тебе это использовать? Когда его использовать?

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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