【问题标题】:Onion architecture compared to hexagonal洋葱结构与六边形相比
【发布时间】:2018-10-06 22:03:25
【问题描述】:

它们之间有什么区别(洋葱|六边形),据我了解,它们是相同的,它们专注于应用程序核心的领域,并且应该与技术/框架无关。

如果有的话,它们之间有什么区别?

另外,我认为使用其中一个甚至针对 N 层架构都没有真正的优势,如果做得不好,仅仅遵循其中任何一个都不会产生任何影响

使用一个比另一个有什么好处?为什么要使用它?什么时候用?

谢谢

【问题讨论】:

  • “如果做得不好”几乎不是选择的标准。

标签: architecture software-design onion-architecture hexagonal-architecture


【解决方案1】:

分层架构和洋葱相关的架构家族之间存在差异。分层架构使用用户界面和数据访问层之间的层次关系。相比之下,洋葱架构将 UI 和数据访问视为同一层的一部分。

为什么用户界面和数据访问在同一层?洋葱架构的核心在于具有业务逻辑的域。这是主要焦点。域不在任何其他层之上或之下。它是最中心的。用户界面、rest 端点等是域的辅助,就像数据存储库一样。

ports and adapters architecture(这是六边形架构的另一个名称)通过其名称清楚地表明了这一点:有任意数量的端口充当域和外部之间的接口。适配器实现端口,以便端口可以与域交互。


编辑:我理解“洋葱架构将 UI 和数据访问视为同一层的一部分”的措辞可以以与预期不同的方式进行解释。关键是在洋葱架构中,用户界面和数据访问功能并不像分层架构那样处于分层关系中。

【讨论】:

    【解决方案2】:

    如果有的话,它们之间有什么区别?

    洋葱:有层,依赖总是指向内部,即一个层可以使用它里面的任何层。内层是领域模型,外层是基础设施,但层数可能会有所不同。

    六边形(它是原始名称“端口和适配器”的替代名称):没有层。您拥有应用程序、端口和适配器。端口属于应用程序,它们是应用程序的 API/SPI。适配器在应用程序之外,每个都依赖于应用程序的一个端口。

    有些人的困惑是,在实现六边形架构时,大多数人并没有将每个适配器物理地放在一个工件中,而是将所有适配器放在一个工件中(如基础设施层)。而且他们还依赖于整个应用程序上的适配器,而不仅仅是他们使用的端口。所以它实际上是一个洋葱。

    实现六边形权利应该将适配器彼此分开,并且每个适配器应该只依赖于它使用/实现的端口(取决于端口是驱动程序还是驱动程序)。

    另一个区别是 Hexagonal 没有说明六边形内部的结构(应用程序)。

    使用一个比另一个有什么好处?

    六边形的好处是它更加模块化,你有一个清晰的组件分离,防止它们之间的代码泄漏。另一方面,洋葱在这个意义上更危险,因为您可以直接从 UI 访问例如数据库(它们都属于同一层)。

    洋葱的好处源于以上。由于六边形有很多工件,如果项目很大,整个项目的构建会花费很多时间。

    你为什么要使用它?什么时候使用?

    使用它们中的任何一个的目的是让您专注于您要解决的实际问题,而不使用任何技术或框架。该应用程序与技术无关,很容易从一个框架迁移到另一个框架。因此,它们都被称为“干净”架构。您的应用程序核心没有框架代码、注释等。

    那么...为什么要使用它们?

    因为您提高了可维护性、可测试性,并且您拥有干净的代码。

    什么时候使用它们?

    我宁愿说什么时候不使用它们。如果您正在开发的应用程序并不复杂,例如,它只是一个 CRUD,则可能不值得使用它们。

    就个人而言,我更喜欢“端口和适配器”。

    希望我的解释有所帮助。

    【讨论】:

    • 另一方面,洋葱在这个意义上更危险,因为您可以直接从 UI 访问例如数据库(它们都属于同一层)。:这种说法是不正确的。
    • 作为@AmitJoshi menetioend,另一方面,“洋葱在这个意义上更危险,因为您可以直接从 UI 访问例如数据库(它们都属于到同一层)”不正确。 UI 和DataBase 不应该存在于同一层! UI 通常属于 Application 层,而 DB 应该位于 Infrastructure 层。
    • @AmitJoshi 恕我直言,我所做的声明并没有错。查看 Jeffrey Palermo jeffreypalermo.com/2008/07/the-onion-architecture-part-1 的图表。他在同一层中绘制 UI 和基础设施(数据库访问等),在应用层(应用服务)之上的一层。所以UI不属于应用层,UI属于应用层之上的层
    • @choquero70 我认为说 UI 和数据库在同一层与您提到的六边形是同一个错误,人们将所有东西都放在一个工件中。洋葱架构有层,但层可以进一步拆分,层内的一般规则是,不允许水平依赖
    • @wasyl 我并不是说洋葱拱门提倡从 UI 访问数据库,我只是说你可以做到,因为它是一个分层拱门,并且两者都在同一层中。在开发人员方面不这样做,但架构允许这样做,因为它们在同一层中,并且洋葱拱模式定义中没有任何地方说这是被禁止的。分层拱门的示例来源:“软件架构模式”一书,Mark Richards,O'Reilly Media,2015 年 2 月。第 1 章,图 1-4,oreilly.com/library/view/software-architecture-patterns/…
    【解决方案3】:

    以前的答案对 Onion 架构做出了根本错误的陈述。他们断言“在 Onion 中,UI 和数据访问是同一层的一部分”。混淆可能来自于认为所有层都与它们上方和下方的所有内容对话。

    实际上,洋葱图是洋葱架构的不良表示。关键要点是核心域层与任何周围层无关,并且周围层通常也彼此无关。通常这意味着 UI 与 Service 对话,后者与 Data 和 Domain 层对话。 UI 不直接与其他层交互,层交互是通过依赖注入和接口隔离抽象出来的。

    据我所知,没有任何架构模式建议混合数据访问和 UI(有些,例如 Active Record,混合业务和数据访问)。另外,有些技术可以生成避免层的代码——快速开发工具通常会这样做,但这些工具更倾向于部署速度而不是设计和可维护性。

    洋葱、六边形、端口和适配器实际上都是同一个概念架构的不同名称。

    Mark Seeman 有一篇很棒的帖子,它有助于阐明差异(如果有的话)是边缘性和语义性的:Layers, Onions, Ports, Adapters: it's all the same

    【讨论】:

    • 恕我直言,我所做的陈述并不正确。看看 Jeffrey Palermo jeffreypalermo.com/2008/07/the-onion-architecture-part-1 的图表。他在同一层中绘制 UI 和基础设施(数据库访问等)。我想说另一件事:这里jeffreypalermo.com/2008/08/the-onion-architecture-part-3 他说给定的层取决于它内部的任何内层,而不仅仅是它下面的层。我说过依赖总是向内的,所以一个层不能和它外面的任何层通信。我对此没有任何困惑
    • 我阅读了第 1 部分和第 3 部分,但我认为他实际上并不是在提倡将基础设施代码混合到一个模块中。 UI 和数据访问等内容显示在同一级别,但他的文字和“扁平洋葱图”暗示它们仍然是独立的层/模块。
    • 他不提倡混合,但从技术上讲,由于两者都在同一层,你可以,虽然你不应该。不混合是由程序员决定的,但架构允许这样做。
    【解决方案4】:

    六边形架构,也称为端口和适配器 关注基础设施问题。

    洋葱架构关注领域问题。

    以持久层为例,您将使用 ORM 来从数据存储中发送和检索数据。 ORM 代表基础架构问题,应该放在域问题之外,这称为适配器,以后可以用另一个 ORM 进行更改。在您的 domani (Onion) 中,您将定义接口,以便您的域不会关心基础设施,这些接口称为端口。

    【讨论】:

      【解决方案5】:

      其中一个区别是,在洋葱架构中,您可以直接从 UI 访问数据库。

      在六边形架构中,任何 UI 对数据库的访问都必须通过 Inbound 端口并遵循域规则。

      【讨论】:

      • 正如目前所写,您的答案尚不清楚。请edit 添加其他详细信息,以帮助其他人了解这如何解决所提出的问题。你可以找到更多关于如何写好答案的信息in the help center
      猜你喜欢
      • 2015-05-19
      • 1970-01-01
      • 1970-01-01
      • 2015-03-17
      • 2011-10-09
      • 2014-06-22
      • 1970-01-01
      • 1970-01-01
      • 2014-10-15
      相关资源
      最近更新 更多