我目前正在研究领域驱动设计，并尝试将其应用于 WPF 项目。我观看了一些教程视频，并阅读了许多文章，例如：
我理解对接口和控制反转的关注。我读到有一些经常性的层名称（表示知识领域的域/核心，持久性的基础设施，应用程序......我不明白），但它们会根据我阅读的文章而改变。有的甚至没有出现。
是否有可能列出所有层，理论上，洋葱架构中需要这些层来面对所有需求和问题，以及它们的意图（它们包含什么样的代码，它们试图满足什么样的需求？ ，他们需要参考哪一层），好吗？
只是一些个人经验，我使用 Eric Even 的 DDD 书中提到的这种架构：
简而言之：
1) 接口由负责与用户（真实端点用户或远程机器）、web mvc 控制器、web 视图对象、远程外观等交互的组件组成。
2) 应用程序定义了您的系统提供的功能。我认为它与接口层高度耦合。如果在 Application 中定义方法，通常还需要添加 Interfaces 类/方法。但是几个接口类/方法可能依赖于同一个应用程序对象，例如，您同时提供一个 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 是邮件上下文中的域模型，但它们是您的域上下文中的基础设施。基础设施层为您将它们分开。
Totally agree with Hippoom's answer. It is perfect to start from there.
Now,
I read there were some recurrent layer names (domain/core for the representation of the sphere of knowledge, infrastructures for persistance, application for ... i don't understand), but they change, depending of articles I read. Some even do not appear.
Yes, decision about layers in an application depends upon many factors in a particular scenario. It is like how a universities divide their programs and make curriculum. It depend upon the capacity/diversity they want to serve, the need in hand and the purpose of university. It is very different in details (naming and partitions) across the globe but the core and intent is always same.
In the same way, Layers in an application depends upon the need and scope. Sometime architects used to define the name of layers as per their philosophy and convention followed in the organization. So sometime the intent and name may differ to some extent. But the code idea of having salable, maintainable and fulfilling the functional and non-functional requirements in hand, remains always same.
Would it be possible to have an list of all layers that, in theory, are required in an onion architecture to face all needs and problems, with their intent (what kind of code do they contain, what kind of need do they try to fulfill, which layer do they need to reference), please ?
Hippoom did it very well already and he described the intent in shot also.
Standard Layers are described here: http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
As I already mentioned layers may differ as per applications need.
Hope it would help you. Thanks.
Included details as per David's first comment below:
Application services implement the use cases and make calls to the Domain Services and Domain Entities and Infrastructure Services in order to get the job done. It provides interfaces to outside world (mainly UI layer projects) to accomplish certain functionalities. For example, UserService is an application service. UserService may provide functionalities to check for authentication for user and authorization for particular resource, change privilege for a user by admin, ban the user etc. To accomplish these use cases, it would use UserRepository and UserEntity from lower layers.
Domain services are application-agnostic; they provide a means to ensure the integrity of the domain model by encapsulating CRUD (Create, Read, Update, Delete) operations and data access. They usually have Repositories of Domain objects and UoW implementation etc in Onion Architecture.