洋葱建筑中的典型层次是什么？
我目前正在研究域驱动设计，并尝试将其应用于WPF项目。 我观看了一些教程video，并阅读了很多文章，例如：
- 同一层中的洋葱架构依赖关系：基础架构和Web通信
- http://eohmicrosoft.blogspot.fr/2012/08/laying-it-out-onion-architecture.html
- 域驱动设计：域服务，应用服务
我理解对接口和控制反转的关注。 我读到有一些经常出现的层名（领域/核心用于表示知识领域，基础设施用于持久性，应用程序用于……我不明白），但它们会根据我阅读的文章而改变。 有些人甚至没有出现。
是否有可能拥有一个理论上在洋葱架构中需要面对所有需求和问题的所有层的列表，它们的意图（它们包含什么样的代码，它们试图满足什么样的需要） ，他们需要参考哪一层），好吗？
完全同意Hippoom的回答。 从那里开始是完美的。
现在，
我读到有一些经常出现的层名（领域/核心用于表示知识领域，基础设施用于持久性，应用程序用于……我不明白），但它们会根据我阅读的文章而改变。 有些人甚至没有出现。
是的，关于应用程序中的层的决定取决于特定场景中的许多因素。 这就像大学如何划分他们的课程和制作课程。 这取决于他们想要服务的能力/多样性，手头的需要和大学的目的。 它在全球范围内的细节（命名和分区）非常不同，但核心和意图总是相同的。
同样，应用程序中的图层取决于需求和范围。 有时候，建筑师根据他们在组织中遵循的哲学和惯例来定义层的名称。 所以有时意图和名称可能会有所不同。 但是，具有可销售性，可维护性和实现function性和非function性要求的代码理念始终如一。
是否有可能拥有一个理论上在洋葱架构中需要面对所有需求和问题的所有层的列表，它们的意图（它们包含什么样的代码，它们试图满足什么样的需要） ，他们需要参考哪一层），好吗？
Hippoom已经做得非常好了，他也描述了拍摄的意图。
标准层在此处描述： http ： //jeffreypalermo.com/blog/the-onion-architecture-part-1/
正如我已经提到的，层可能根据应用需要而有所不同。
希望它会对你有所帮助。 谢谢。
根据David的第一条评论包含的详细信息如下：
应用程序服务实现用例并调用域服务和域实体和基础结构服务以完成工作。 它提供与外部世界（主要是UI层项目）的接口以实现某些function。 例如，UserService是一个应用程序服务。 UserService可以提供检查用户身份validation和特定资源授权的function，管理员更改用户权限，禁止用户等。要完成这些用例，它将使用较低层的UserRepository和UserEntity。
域服务与应用程序无关; 它们提供了一种通过封装CRUD（创建，读取，更新，删除）操作和数据访问来确保域模型完整性的方法。 它们通常在洋葱架构中具有域对象的存储库和UoW实现等。
只是一些个人经验，我使用Eric Even的DDD书中提到的这种架构： 
简而言之：
1）接口由负责与用户（真实端点用户或远程机器），web mvc控制器，web视图对象，远程外观交互的组件组成。
2）应用程序定义了系统提供的function。 我认为它与Interfaces层高度耦合。 如果在Application中定义方法，通常还需要添加Interfaces类/方法。 但是，有几个Interfaces类/方法可能依赖于同一个Application对象，例如，您为场所顺序提供了web ui和web服务。
3）域，系统中最稳定的部分。 例如，在语言上下文中，单词/句子是具有其自身含义的Domain对象，我将它们组合起来形成这个答案。 所以你可以认为我是一个应用程序对象，虽然不是一个好的因为我不会说一口流利的英语：P
4）Infrstructure，实际上我不认为这是一层，它实现了以上三种。 例如，您的域层中有一个OrderRepository接口，您可以使用某个orm框架（持久性基础架构）来实现它。 我的大多数基础结构对象都是适配器（在Application / Domain / Interfaces层实现一个接口，并适应外部组件，如数据库，消息提供程序，邮件服务器等）。
希望这可以帮助。
基础架构意图更新：
这是我们项目的包视图之一。
基础结构层中有一些适配器：
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接口，它对特定function非常具体。 主题，内容取决于应用层/域层。 我们在同一个包中提供了使用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是邮件上下文中的域模型，但它们是域上下文中的基础结构。 基础架构层为您分隔它们。