Question

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

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

是否有可能拥有一个理论上洋葱架构中需要面对所有需求和问题的所有层的列表，它们的意图（它们包含什么样的代码，它们需要什么样的类型）试着去实现，他们需要引用哪一层），拜托？

Answer 1

仅仅是一些个人经历，我使用Eric Even的DDD书中提到的这种架构： enter image description here

简而言之：

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

2）应用程序定义了系统提供的功能。我认为它与Interfaces层高度耦合。如果在Application中定义方法，通常还需要添加Interfaces类/方法。但是，有些Interfaces类/方法可能依赖于同一个Application对象，例如，您可以为场所顺序提供web ui和Web服务。

3）域，系统中最稳定的部分。例如，在语言上下文中，单词/句子是具有其自身含义的Domain对象，我将它们组合起来形成这个答案。所以你可以认为我是一个应用程序对象，虽然不是一个好的因为我不会说一口流利的英语：P

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

希望这有帮助。

基础架构意图更新：

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

enter image description here

基础架构层中有一些适配器：

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

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

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

4.infrastructure.persistence包含数据库的适配器，我们为域存储库提供了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();
 }

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

Answer 2

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

现在，

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

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

同样，应用程序中的图层取决于需求和范围。有时，建筑师根据他们在组织中遵循的理念和惯例来定义层的名称。所以有时意图和名称可能会有所不同。但是，掌握可销售，可维护和实现functional and non-functional requirements的代码理念始终如一。

理论上，是否可以列出所有图层的列表在洋葱建筑中需要面对所有需求和问题，与他们的意图（他们包含什么样的代码，什么样的需要他们尝试实现，他们需要参考哪一层），拜托？

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

希望它会对你有所帮助。谢谢。

根据David的第一条评论包含的详细信息：

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

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

洋葱建筑中的典型层次是什么？

2 个答案: