问题描述
我目前正在研究的领域驱动设计，并尝试应用它的WPF项目。我看了一些视频教程，和看了很多文章，如：
I am currently studying the domain driven design, and try to apply it for a WPF project. I watched some tutorial videos, and read many articles, like :
- Onion archicecture相关性在同一层：基础设施和网络通信
- 的
- Domain驱动设计：域名服务，应用服务
- 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
我了解的重点接口和控制反转。我看有一些经常性的图层名称（域名/核心知识领域的重新presentation，基础设施持久性，应用程序......我不明白），但他们改变，这取决于文章我读。有些人甚至不会出现。
I understood the focus on interfaces and inversion of control. 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.
难道是可能有，在理论上，都需要在洋葱架构来面对所有的需求和问题，所有层的列表，用自己的意图（不含有什么样的code，是什么样的需要做的，他们试图完成，这层，他们需要多参考），好吗？
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的答案。这是完美的，从那里开始。
Totally agree with Hippoom's answer. It is perfect to start from there.
现在，
我看有一些经常性的图层名称（域名/核心的 重知识领域的presentation，基础设施 持久性，应用程序......我不明白），但他们改变， 根据文章中，我读出。有些人甚至不会出现。
是的，关于层在应用程序的决定取决于许多因素，在特定的情况下。它就像一所大学如何划分他们的节目，使课程。这取决于容量/多样性，他们希望服务，需要在手，大学的目的。它是在细节（命名和分区）在全球范围内，但所述芯非常不同，并且意图始终是一样的。
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.
在以同样的方式，在应用程序层取决于需要和范围。用来定义层按他们的理念和公约的名称有时建筑师遵循的组织。因此，一段时间的意图和名称可能会有所不同在一定程度上。但有出售，维护和实现functional和非功能性要求在手，总是保持相同。
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.
是否可以将所有层的列表，从理论上讲， 下所需要的洋葱架构来面对所有的需求和问题， 他们的意图（不含有什么样的code，是什么样的 需要做的，他们试图完成，哪一层？他们需要参考） 好吗？
Hippoom做的非常好已经和他描述的出手的意图也。
标准层的描述如下：http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
正如我已经提到的层可不同，如每个应用程序所需要的。
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.
包含的信息按以下大卫的第一个注释：
应用服务执行用例，为了把工作做好拨打电话到域服务和域实体和基础设施服务。它提供到外部世界（主要是UI层的项目）来完成某些功能。例如，UserService的是一个应用程序的服务。 UserService的可提供的功能，以检查对于用户和授权对于特定的资源，变更特权者：用户认证，禁止用户等为了完成这些使用情况下，它会使用UserRepository和UserEntity从下层。
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.
域名服务是与应用无关;它们提供了一种装置，通过封装CRUD（创建，读取，更新，删除）的操作和数据访问，以确保域模型的完整性。他们通常有域对象和 UOW 的洋葱架构的实施等。
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.
这篇关于什么是洋葱架构典型的层次？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！