洋葱架构中的典型层是啥？

Posted 2023-03-08

【中文标题】洋葱架构中的典型层是啥？

【英文标题】：What are the typical layers in an onion architecture?洋葱架构中的典型层是什么？

【发布时间】：2013-08-12 13:39:42

【问题描述】：

我目前正在研究领域驱动设计，并尝试将其应用于 WPF 项目。我看了一些教程视频，阅读了很多文章，比如：

Onion archicecture dependencies in the same layer: Infrastructure and Web communicating http://eohmicrosoft.blogspot.fr/2012/08/laying-it-out-onion-architecture.html Domain Driven Design: Domain Service, Application Service

我理解对接口和控制反转的关注。我读到有一些经常性的层名称（表示知识领域的域/核心，持久性的基础设施，应用程序......我不明白），但它们会根据我阅读的文章而改变。有些甚至没有出现。

是否有可能列出所有层，理论上，洋葱架构中需要这些层来面对所有需求和问题，以及它们的意图（它们包含什么样的代码，它们有什么样的需求？尝试完成，需要参考哪一层），好吗？

【参考方案1】：

只是一些个人经验，我使用的是 Eric Even 的 DDD 书中提到的这个架构：

简而言之：

1) 接口由负责与用户（真正的端点用户或远程机器）、web mvc 控制器、web 视图对象、远程外观等交互的组件组成。

2) 应用程序定义了您的系统提供的功能。我认为它与接口层高度耦合。如果在 Application 中定义方法，通常还需要添加 Interfaces 类/方法。但是多个接口类/方法可能依赖于同一个 Application 对象，例如，您同时提供 web ui 和 web 服务用于下订单。

3) 域，系统中最稳定的部分。例如，在语言上下文中，单词/句子是具有自己含义的域对象，我将它们组织起来形成这个答案。因此，您可以将我视为 Application 对象，尽管不是一个好的对象，因为我不会说流利的英语：P

4) Infrstructure，其实我不认为这是一个层，它实现了以上三个。例如，您在域层中有一个接口 OrderRepository，您可以使用一些 orm 框架（持久性基础设施）来实现它。我的大部分基础设施对象都是适配器（在 Application/Domain/Interfaces 层实现接口并适应外部组件，如数据库、消息传递提供程序、邮件服务器等）。

希望这会有所帮助。

基础设施意图更新：

这是我们项目的包视图之一。

基础设施层有一些适配器：

1.infrastructure.channel.XXX 每个包都包含几个特定在线支付提供商的适配器。

2.infrastructure.payment 包含我们组织的支付系统的适配器，但它位于另一个有界上下文中。我们使用 MakePaymentService（一种域服务）将支付系统与该系统的其他部分解耦。

3.infrastructure.messaging 包含消息传递提供者的适配器，我们为 PaymentWasMadeNotifier（应用服务）提供了一个 jms 实现

4.infrastructure.persistence 包含数据库适配器，我们为 Domain Repositories 提供 iBATIS（Java 中的 orm 框架）。

以上这些适配器都在Application/Domain层实现了一些接口。 下面是一些“服务”，但它们是通用的：

5.infrastructure.mail

6.infrastructure.logging

7.infrastructure.security

上面的这些包暴露了一些接口和实现。例如，我们提供了一个 MailManager 接口，它与特定功能无关。主题、内容取决于应用层/领域层。我们在同一个包中提供了一个使用 javamail 的实现。

public interface MailManager 
void send(String subject, String content);

8.infrastructure.time 这个很特别，我们在这个系统中有一些 cron 工作，所以我们引入了一个 Clock 来将时间与工作设置解耦，因此它对测试很友好（想象一下我们有一个工作，它应该在每个月的25号启动，我们可以通过将当前时间设置为25号来测试作业，即使是今天的1号）。我们在持久化包中提供了一个实现（由于某些原因，我们需要在生产中使用数据库的时间）

 public interface Clock     
    Date now();
 

所以我的理解是：基础设施为您的其他三层提供服务/实现，但它们是特定于技术的。例如，主题、内容、发件人、收件人、cc 是邮件上下文中的域模型，但它们是您的域上下文中的基础设施。基础设施层为您将它们分开。

【讨论】：

所以，快速总结一下，领域层代表领域的抽象，应用层代表额外的非本地特性，我们提供的领域之上的功能，接口都是 ui 项目（wpf 、silverlight、asp.net 网络表单/mvc) ?我开始掌握这个概念，但我仍然对基础设施层感到不安。基本上，它是一个巨大的“实用程序/放置任何你想要的东西/将抽象的实现放在 Int./A/D 层”层？每当 Int./A/D 层存在紧密耦合时，您只需将其接口并在 Infrastructure 中实现？

【参考方案2】：

完全同意 Hippoom 的回答。从那里开始是完美的。

现在，

我读到有一些循环层名称（域/核心 知识领域的代表，基础设施 持久性，申请......我不明白），但他们改变了， 取决于我读过的文章。有些甚至没有出现。

是的，关于应用程序中的层的决定取决于特定场景中的许多因素。这就像大学如何划分课程并制定课程一样。这取决于他们想要服务的能力/多样性、手头的需求和大学的目的。它在全球范围内的细节（命名和分区）非常不同，但核心和意图始终相同。

同样，应用程序中的层取决于需求和范围。有时架构师会根据他们在组织中遵循的理念和约定来定义层的名称。因此，有时意图和名称可能会有所不同。但是，拥有可销售、可维护和实现 functional and non-functional requirements 的代码理念始终保持不变。

是否有可能列出所有层的列表，理论上， 在洋葱架构中需要面对所有需求和问题， 与他们的意图（他们包含什么样的代码，什么样的 他们是否需要尝试完成，他们需要参考哪一层）， 请问？

Hippoom 已经做得很好了，他也在镜头中描述了意图。 此处描述了标准层：http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ 正如我已经提到的，层可能会根据应用程序的需要而有所不同。

希望对您有所帮助。谢谢。

根据大卫在下面的第一条评论包含详细信息：

应用程序服务实现用例并调用域服务和域实体和基础设施服务以完成工作。它为外部世界（主要是 UI 层项目）提供接口以完成某些功能。例如，UserService 是一个应用程序服务。 UserService 可以提供功能来检查用户的身份验证和特定资源的授权，通过管理员更改用户的权限，禁止用户等。为了完成这些用例，它将使用来自较低层的 UserRepository 和 UserEntity。

域服务与应用程序无关；它们提供了一种通过封装 CRUD（创建、读取、更新、删除）操作和数据访问来确保域模型完整性的方法。它们通常在 Onion 架构中具有域对象的存储库和 UoW 实现等。

【讨论】：

我阅读了您链接的上一篇文章它似乎与 Hippoom 的答案有很多相似之处。但我不明白为什么某些层的名称中有“服务”。领域服务，应用服务。请给我解释一下意思好吗？

该链接上的域服务和应用程序服务与 Hippoom 的回答中的域和应用程序层的作用相同。这只是命名转换差异。由于此处评论的字数限制，我已将应用程序服务和域服务详细信息包含在答案的底部。谢谢。

感谢您的回答。我想我还有最后三个问题。什么是基础设施层，它应该包含什么？表示逻辑在哪里（是 UI/Presentation/Interfaces 层）？

非常欢迎！基础设施层具有基础设施问题，例如与数据库交互（数据库设置等，显然它将用于具有对域实体执行 CRUD 的逻辑的其他层），通过网络进行通信（如果外部 Web 服务，如 paypal 或任何 FTP 调用等），通过 SMTP 等发送电子邮件。表示逻辑进入 UI/表示/接口层。 UI 层关心你想要显示数据的方式，它可能有客户端验证和动画等。如果你在 UI 中使用这些。希望它会有所帮助。谢谢。

@PraveenPrajapati 所以总的来说“UI”、“Presentation”和“Interfaces”在这里是一样的吗？而且基础设施和数据访问层基本一样吧？