一.基础知识准备：
1.层的原则：
（1）每一层以接口方式供上层调用。 （2）上层只能调用下层。 （3）依赖分为松散交互和严格交互两种。
2.业务逻辑分类：
（1）应用逻辑。 （2）领域逻辑。
3.采用的层：
（1）表示层（用户接口层）：领域无关。 （2）服务层（应用层）：应用逻辑。 （3）业务逻辑层（领域层）：领域逻辑。 （4）共享层：提供通用代码。 （5）实现层：提供接口实现。
4.约定：
（1）领域层默认采用领域模型 （2）数据访问层默认需要引用领域模型
二.分层架构
分层架构的三个基本层次为：表示层、业务逻辑层和数据访问层。如果按照业务逻辑的分类将业务逻辑层分解为服务层和领域层，则三层扩展为四个层次：表示层、服务层、领域层和数据访问层。数据访问层一般必须了解领域模型，这将在层之间产生双向依赖，通常我们有如下两种解决方案：
1.将领域模型放置在共享层：
评价：PetShop采用此种模型，但缺点众多：业务逻辑层名不副实，领域模型实为数据模型，保持了层间依赖，引入了更多依赖，明显的数据驱动思想，没有以领域为核心。
2.将数据访问接口定义在业务逻辑层：
评价：NopCommerce采用此种模型，即使采用分离出了服务层和采用了资源库命名方式，但NopCommerce不是DDD分层架构，只是采用了领域模型和接口分离原则的普通三层架构。缺点：除了数据房产，没有将其他具体的技术依赖从业务逻辑层中分离。
三.DDD分层：
DDD分层明确的将业务逻辑层分成了应用层（服务层）和领域层两部分。同时将数据访问和其他接口的具体技术实现部分统一到了基础设施层。
1.原始的DDD分层：
评价：优点是将具体技术实现从领域分离，基础设施层复用价值增加。缺点是没有使用共享和实现的概念细分基础设施层，导致在基础设施层中实现仓储会产生反向依赖，虽然在单项目解决方案中没有影响（仅命名空间层次的形式上的依赖），但在.NET多项目解决方案中，只能通过接口分离方式将仓储实现独立成类似数据访问层的方式。
2.改善的DDD分层：
评价：基础设施层同时具有共享层和实现层的特征。优点是终于做到了形式上领域为核心且同时解决了在基础设施层中实现仓储不能引用领域模型的尴尬，缺点是同样没有区分共享和实现的概念。
3.最新的DDD分层：
评价：优点是这是真正的以领域为核心，再也不用为基础设施层无法引用领域层而再服务层中再次适配了。使用依赖倒置原则彻底各层对具体技术的依赖倒置。缺点，依赖倒置应用过了头，同样是在单项目解决方案中没有问题，但在.NET多项目解决方案中会导致命名空间形式上的双向依赖。基础设施层作为实现层基本上没有了复用的价值。更好的方式是调换图中用户接口层和基础设施层的位置。
可以根据需要考虑在上图添加适当的共享层。
四.架构的趋势：
（1）以业务逻辑为核心，更加重视业务逻辑。 （2）将业务逻辑层的具体依赖划分到一个层次统一管理。 （3）更加重视降低解决方案内的依赖性而不是解决方案间的代码复用。 （4）共享层和实现层的分离将会越来越多的体现。例如洋葱型架构。
参考
1.Patterns of Enterprise Application Architecture 【企业应用架构模式】 2.Domain-Driven Design 【领域驱动设计：软件核心复杂性应对之道】 3.Applying Domain-Driven Design and Patterns【领域驱动设计与模式实战】 4.Implementing Domain-Driven Design 【实现领域驱动设计】 5.Microsoft Application Architecture Guide 【微软应用架构指南（第2版）】 6.Professional Enterprise .NET 【精通.NET企业项目开发：最新的模式、工具与方法】 7.Professional ASP.NET Design Patterns 【ASP.NET设计模式】
- 1楼梦在旅途
- 我觉得架构最终要实现的目标是：易复用，易扩展，易替换。一味的追求各种架构，容易陷入误区，从而把简单的事情复杂化，我觉得没有完美的架构，只有合适的架构，我们应该在开发设计时，将可能存在变化的部份拿出来进行分析设计，使用能适用变化，不变的部份，怎么简单怎么设计。