Луковая архитектура по сравнению с шестиугольной
Есть ли какая-то разница между ними (лук | шестиугольник), насколько я понимаю, они одинаковы, они сосредоточены на области, которая лежит в основе приложения и должна быть независимой от технологии / инфраструктуры.
Каковы различия между ними, если таковые имеются?
Кроме того, я не вижу никакого реального преимущества в использовании одного над другим или даже против N-слоистой архитектуры, если плохое выполнение, если просто следовать одному из них, не будет иметь никакого значения
Каковы преимущества использования одного над другим и почему вы бы его использовали? когда его использовать?
Спасибо
5 ответов
Каковы различия между ними, если таковые имеются?
Лук: Существуют слои с зависимостями, всегда указывающими внутрь, т. Е. Слой может использовать любой из слоев внутри него. Внутренний слой - это Модель предметной области, а внешний - инфраструктура, но число слоев между ними может варьироваться.
Шестиугольная (это альтернативное название для первоначального названия "Порты и адаптеры"): нет слоев. У вас есть приложение, порты и адаптеры. Порты принадлежат приложению, они являются API/SPI приложения. Адаптеры находятся вне приложения, и каждый из них зависит от порта приложения.
У некоторых людей возникает путаница, заключающаяся в том, что при реализации гексагональной архитектуры большинство людей физически не помещает каждый адаптер в артефакт, а объединяет все в один артефакт (например, слой инфраструктуры). Кроме того, они зависят от адаптеров во всем приложении, а не только от порта, который они используют. Так что на самом деле это будет лук.
Реализация гексагонального права должна отделять адаптеры друг от друга, и каждый адаптер должен зависеть только от порта, который он использует / реализует (в зависимости от того, является ли порт драйверным или управляемым).
Другое отличие состоит в том, что Hexagonal ничего не говорит о структуре внутренней части шестиугольника (приложение).
Каковы преимущества использования одного над другим?
Преимущество шестиугольника в том, что он более модульный, у вас есть четкое разделение компонентов, предотвращающее утечку кода между ними. Лук, с другой стороны, более опасен в этом смысле, так как вы можете получить доступ, например, к базе данных непосредственно из пользовательского интерфейса (они оба принадлежат одному и тому же слою).
Выгода от лука получается из вышесказанного. Поскольку у шестиугольника много артефактов, если проект большой, сборка всего проекта должна занять много времени.
Зачем тебе это использовать? когда его использовать?
Смысл использования любого из них заключается в том, что вы сосредотачиваетесь на реальной проблеме, которую пытаетесь решить, без использования каких-либо технологий или инфраструктуры. Приложение не зависит от технологий, и его легко перенести с одного фреймворка на другой. Из-за этого их обоих называют "чистыми" архитектурами. У вас есть ядро приложения без кода платформы, аннотаций и т. Д.
Итак... Зачем их использовать?
Потому что вы улучшаете удобство обслуживания, тестируемость и получаете чистый код.
Когда их использовать?
Я бы лучше сказал, когда их не использовать. Если приложение, которое вы разрабатываете, не является сложным, например, это просто CRUD, возможно, оно не заслуживает их использования.
Лично мне больше нравятся "Порты и адаптеры".
Надеюсь, что мое объяснение помогло.
Предыдущие ответы содержат в корне неверное утверждение об архитектуре Onion. Они утверждают, что "в Onion пользовательский интерфейс и доступ к данным являются частью одного уровня". Путаница может возникнуть из-за того, что все слои взаимодействуют со всем, что находится выше и ниже них.
На самом деле луковая диаграмма - плохое представление луковой архитектуры. Ключевой вывод заключается в том, что уровень ядра домена не зависит от любых окружающих слоев, а окружающие слои обычно также не зависят друг от друга. Обычно это означает, что пользовательский интерфейс взаимодействует со службой, которая взаимодействует с уровнями данных и домена. Пользовательский интерфейс не взаимодействует напрямую с другими уровнями, а взаимодействия между уровнями абстрагируются с помощью внедрения зависимостей и разделения интерфейса.
Насколько мне известно, нет никаких архитектурных шаблонов, рекомендующих смешивать доступ к данным и пользовательский интерфейс (некоторые, такие как Active Record, смешивают бизнес и доступ к данным). По отдельности существуют технологии, которые создают код, избегающий слоев - часто это делают инструменты быстрой разработки, но это инструменты, которые предпочитают скорость развертывания дизайну и удобству обслуживания.
Луковица, Гексагональная, Порты и Адаптеры - это на самом деле разные названия одной и той же концептуальной архитектуры.
У Марка Симана есть отличный пост, который помогает прояснить, насколько различия, если таковые имеются, являются маргинальными и семантическими: Layers, Onions, Ports, Adapters: это все одно и то же
Гексагональная архитектура, также известная как порты, ориентирована на проблемы инфраструктуры.
Луковая архитектура фокусируется на проблемах предметной области.
Взяв пример уровня сохраняемости, вы должны использовать ORM для отправки и извлечения данных из хранилища данных. ORM представляет собой проблему инфраструктуры и должен быть размещен за пределами проблем домена, это называется адаптером и может быть позже изменен с помощью другого ORM. Внутри вашего domani (Onion) вы должны определить интерфейсы, чтобы ваш домен не был связан с инфраструктурой, эти интерфейсы называются портами.
Существует различие между многоуровневой архитектурой и семейством архитектур, связанных с луком. Многоуровневая архитектура работает с иерархической взаимосвязью между пользовательским интерфейсом и уровнями доступа к данным. В отличие от этого, архитектура лука рассматривает пользовательский интерфейс и доступ к данным как часть одного и того же уровня.
Почему пользовательский интерфейс и доступ к данным находятся на одном уровне? В основе луковой архитектуры лежит домен с его бизнес-логикой. Это основной фокус. Домен не находится выше или ниже любого другого слоя. Это самый центр. Пользовательские интерфейсы, конечные точки отдыха и т.п. являются вторичными по отношению к домену, так же как и хранилища данных.
Архитектура портов и адаптеров (которая является еще одним названием для гексагональной архитектуры) проясняет это по ее названию: существует любое количество портов, которые действуют как интерфейсы между доменом и внешней средой. Адаптеры реализуют порты, чтобы порты могли взаимодействовать с доменом.
Одно из отличий заключается в том, что в луковой архитектуре вы можете получить доступ к базе данных непосредственно из пользовательского интерфейса.
В шестиугольной архитектуре любой доступ пользовательского интерфейса к базе данных должен осуществляться через входящий порт и соответствовать правилам домена.