多层设计中各个分层核心关注的内容：
Domain Model Layer
The “Domain Model Layer” is the Heart of the Software. 负责业务概念、流程和领域规则
This layer should be responsible for representing business concepts, information on the status of the business processes and implementation of domain rules. It should also contain states reflecting the status of business processes, even when the technical storage details are delegated to the lower layers of the infrastructure (Repositories, etc.)
The components of this layer implement the system core functionality and encapsulate all the relevant business logic (generally called Domain logic according to DDD terminology). Basically, this layer usually contains classes which implement the domain logic within their methods, although it can also be implemented using a dynamic business rule system, etc.
Following the architecture patterns in DDD, this layer must completely ignore the data persistence details. These persistence tasks should be performed by the infrastructure layer.
The main reason for implementing the domain logic layer (business) is to differentiate and clearly separate the behavior of the domain rules (business rules that are the responsibility of the domain model) and the infrastructure implementation details (like data access and specific repositories linked to a particular technology such as O/RMs, or simply data access libraries or even cross-cutting aspects of the architecture). Thus, by isolating the application Domain, we will drastically increase the maintainability of our system and we could even replace the lower layers (data access, O/RMs, and databases) with low impact to the rest of the application.
Data Persistence Infrastructure Layer
实现数据的存储机制
The data persistence components provide access to the data hosted within the boundaries of our system (e.g., our main database which is within a specific BOUNDED CONTEXT), and also to the data exposed outside the boundaries of our system, such as Web services of external systems. Therefore, it has components like “Repositories” that provide such functionality to access the data hosted within the boundaries of our system, or “Service Agents” that will consume Web Services exposed by other external backend systems. In addition, this layer will usually have base classes/components with reusable code for all the repository classes.
Application Layer
协调应用的各种活动，但不包括业务逻辑和业务状态
The Application layer should be a Layer that coordinates the activities of the Application as such, but it is essential that it does not include any domain logic or business/domain state. However, it can contain progress states of the application tasks.
The SERVICES that typically reside within this layer (remember that the SERVICE pattern is applicable to different Architecture layers), are services that usually coordinate the SERVICES and objects of other lower level layers.
The most common case of an Application Service is a Service that coordinates all the “plumbing” of the application, that is, orchestration of calls to the Domain Services and later, calls to Repositories to perform persistence, using UoW, transactions, etc.
Another more collateral case would be a SERVICE of the APPLICATION layer responsible for receiving E-Commerce purchase orders in a specific XML format. In this scenario, the APPLICATION layer will be responsible for reformatting/rebuilding such Purchase Orders from the original XML received and converting them into Domain Model ENTITY objects. This example is a typical case of APPLICATION logic. We need to perform a format conversion, which is a requirement of the application and not something that forms part of the Domain logic, so it should not be located in the Domain layer but rather in the Application layer.
key patterns / 关键的模式
| Categories | Patterns |
| Application layer components | Application Façade Chain of Responsibility Command |
| Concurrency and transactions | Capture Transaction Details Coarse-Grained Lock Implicit Lock Optimistic Offline Lock Pessimistic Offline Lock Transaction Script |
| Workflows | Data-driven workflow Human workflow Sequential workflow State-driven workflow |
The Distributed Services Layer
实现通道（通讯）的重用
The Service Layer typically exposes the following topics:
- Services: Services expose interfaces that receive incoming messages. In short, services are like a façade layer for remote clients. Services expose the application and domain logic to the potential consumers such as Presentation Layer or other remote Services/Applications.
- Message Types: In order to exchange data via the Service Layer, data structures are serialized to messages. The service layer will also expose data types and contracts that define the data types used in the messages (like DTOs or Resource Representations), although these data classes could be defined within the Application Layer instead of the Distributed Services Layer, so they can be re-used from different channels (direct .NET CLR, etc.).
In a Microsoft platform, we can currently choose between two message oriented base technologies and Web services / 可用的技术
- ASP.NET Web Services (ASMX)
- Windows Communication Foundation (WCF)
- Workflow-Services ‟WCF+WF‟‟)
- RAD (Rapid Application Development):
o WCF Data.Services (aka. ADO.NET DS)
o Implementation of OData from Microsoft.
o WCF RIA Services
Presentation Layer
这个是都比较熟悉的部分，软件的最终展示部分，主要的类型和模式有
| Archetype | Technology | Architecture Pattern – Presentation layer |
| Rich applications (Desktop applications / Windows) | WPF/Silverlight WinForms | MVVM MVP |
| Web applications (HTML dynamic applications) | ASP.NET MVC ASP.NET Forms | MVC MVP |
| RIA applications | Silverlight HTML 5 and JavaScript | MVVM MVVM |
| Mobile applications | Silverlight Mobile | MVVM |
| OBA Applications (Office) | .NET VSTO | MVP |
Cross-cutting Infrastructure Concerns
跨越各个层的处理，AOP就是这方面的关注点
Most applications have common functionality used by the different logical layers and even in different physical Tiers. In general, this type of functionality covers operations like authentication, authorization, cache, exception management, logging, tracking, instrumentation and validation.
All these aspects are commonly called “Cross-cutting concerns” or “Horizontal concerns” because they affect the entire application and we should be able to reuse these components from the different layers.
整个软件系统通过如上的分层，架构清晰、职责分明，对于大型项目和TDD等很合适，当然由于层次的分割对软件效率会一定的影响，但相对来说可以忽略。不过实际中我们遇到的一些短期、人数比较小的项目，RAD方式相对还是比较高效的，分层就没有这么多了。
因此具体如何选择和实现，需要根据具体的场景进行选择。