c# - 洋葱架构中的典型层是什么？

Question

我目前正在研究领域驱动设计，并尝试将其应用到一个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

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

是否有可能列出所有层，理论上，洋葱架构需要这些层来面对所有需求和问题，以及它们的意图(它们包含什么样的代码，它们有什么样的需求)请尝试实现，他们需要引用哪一层)？

Answer 1

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

简而言之:

1) 接口(interface)由负责与用户(真实端点用户或远程机器)、web mvc Controller 、web View 对象、远程外观等交互的组件组成。

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

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

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

希望这对您有所帮助。

基础设施意图更新:

这是我们项目的包 View 之一。

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

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

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

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

4.infrastructure.persistence 包含数据库适配器，我们为域存储库提供 iBATIS(Java 中的 orm 框架)。

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

5.infrastructure.mail

6.基础设施.日志记录

7.基础设施.安全

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

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

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

 public interface Clock {    
    Date now();
 }

所以我的理解是:基础设施为您的其他三层提供服务/实现，但它们是特定于技术的。例如，Subject、content、from、to、cc 在邮件上下文中是域模型，但在您的域上下文中它们是基础设施。基础架构层为您将它们分开。