DDD(Domain Driven Design) 架构设计

1、为何要分层

分层架构是全部架构的鼻祖，分层的做用就是隔离，不过，咱们有时候有个误解，就是把层和程序集对应起来，就好比简单三层架构中，在你的解决方案中，通常会有三个程序集项目：XXUI.dll、XXBLL.dll 和 XXDAL.dll，而后把这三个程序集当作一个层，这没什么不能够，但当项目复杂的时候，若是还按照这种方式的话，你的程序集中的文件夹会愈来愈多，程序集也会愈来愈大。当你的视野跳出这个程序集的概念后，你会发现，层不仅是和程序集对应，也和解决方案文件夹，或者是整个解决方案对应，一个层甚至能够对应一个系统。

分层的目的即为了“高内聚低耦合”的思想。

2、微软经典的三层架构

任何一个.net都知道的微软的三层架构，三层架构就是把业务划分为界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。以下图

各层的做用：

界面层(UI)：主要表示WEB方式，也能够表示成WINFORM方式;若是逻辑层至关强大和完善，不管表现层如何定义和更改，逻辑层都能完善地提供服务。主要对用户的请求接受，以及数据的返回。

业务逻辑层(BLL)：主要是针对具体的问题的操做，也能够理解成对数据层的操做，对数据业务逻辑处理，若是说数据层是积木，那逻辑层就是对这些积木的搭建。

数据访问层（DAL）：主要看数据层里面有没有包含逻辑处理，实际上它的各个函数主要完成各个对数据文件的操做。而没必要管其余操做。

在开发人员眼里，一个业务系统的分层只是技术架构上的，因此会把日志纪录、权限管理、数据库持久化、消息服务等等，把一些能分离出来的尽可能分离出来，而后再把这些东西组合起来，就成了系统帮助层，它们贯彻于整个业务系统。

三层架构是典型事务脚本逻辑结构，一个复杂的业务都在BBL方法体中从头至尾描述，处理高度复杂的业务显得无能为力！！！

估计全部的.NET 程序员都是从这个经典的三层的架构一步一步走过来的。

3、DDD经典分层

DDD：领域驱动设计

TDD：是测试驱动开发 

POEAA：企业应用架构模式

DDD核心思想是由业务问题来控制解决方案的形式从以数据库为中心过渡到领域模型为中心 

下面这个图是我在《领域驱动设计与模式实战》书中拍下来的，他彻底诠释DDD的经典分层。

各层概念：

表现层（Presentation Layer）：图中的用户界面层包括用户接口层，用户输入和数据展现。

应用层（Application Layer）：应用层定义系统的业务功能，并指挥领域层中的领域对象实现这些功能。

领域层（Domain Layer）：核心层，实现全部业务逻辑。

基础设施层（Infrastructure Layer）：提供整个业务系统的基础服务。

各层在编译时的类依赖关系以下图（这是一个很矮矬穷的图）：

高层模块不该该依赖于底层模块，二者都应该依赖于抽象

抽象不该该依赖于细节，细节应该依赖于抽象。

4、ABP分层

上节FirstABP的解决方案：

ABP详细分层：

咱们从上到下看看都是什么意思：

表示层

Presentation：

View Models (Javascript)：=

Views (HTML/CSS)：=

Localization,  Navigation, Notifications：多语言，菜单，通知

web：

Web API Controllers：webapi接口

MVC Controllers, OData：OData是什么我也不知道

应用层（Application）

Application Services：应用服务

DTOs：数据传输对象

DTO Mappers：AutoMapper进行实体与DTO之间的映射

Authorization：参数验证

Session：

Audit Logging：审计日志

应用层提供一些应用服务（Application Services）方法供展示层调用。一个应用服务方法接收一个DTO(数据传输对象)做为输入参数，使用这个输入参数执行特定的领域层操做，并根据须要可返回另外一个DTO。在展示层到领域层之间，不该该接收或返回实体(Entity)对象，应该进行DTO映射。一个应用服务方法一般被认为是一个工做单元（Unit of Work）。用户输入参数的验证工做也应该在应用层实现。ABP提供了一个基础架构让咱们很容易地实现输入参数有效性验证。建议使用一种像AutoMapper这样的工具来进行实体与DTO之间的映射。

领域层（Domain(Core)）

Entities:实体，领域对象，表明业务领域的数据和操做

value objects：实体模型

Repositories：仓储，用来操做数据库进行数据存取。仓储接口在领域层定义，而仓储的实现类应该写在基础设施层。

Domain Services：领域服务，当处理的业务规则跨越两个（及以上）实体时，应该写在领域服务方法里面。

Domain Event：领域事件，在领域层某些特定状况发生时能够触发领域事件，而且在相应地方捕获并处理它们。

Unit of Work：工做单元，一种设计模式，用于维护一个由已经被修改(如增长、删除和更新等)的业务对象组成的列表。它负责协调这些业务对象的持久化工做及并发问题。

基础设施（Infrastructure）

ORM (EntityFramework, NHibernate)：ORM框架，ABP提供了EF和NHibernate支持

DB Migrations：EF Code First建立数据库用的

Background Jobs：做业调度和自动任务，（相似Quartz.NET）

补充（单页面应用和多页面应用）

在单页面应用中（SPA）,全部的资源都会一次性加载到客户端（或者只加载核心资源，懒加载其余资源），全部的后续和服务器的交互都是经过Ajax调用。Html代码是使用从服务端接收到的数据在客户端生成的。整个页面不会刷新，视图只是在必要时换入换出。有许多的Javascript SPA框架，好比AngularJs，DurandalJs,BackboneJs和EmberJs。ABP可使用它们中的任何一个，可是提供了使用 AngularJs和DurandalJs的样例。

在多页面（经典）应用中(MPA)，客户端向服务端发送请求，服务端代码（ASP.NET MVC 控制器）从数据库中获取数据，而后Razor视图引擎生成html 代码。这些编译后的页面发回给客户端显示。每一个新的页面都会致使完整页面的刷新。

SPA和MPA涉及了彻底不一样的架构。对于后台管理系统来讲，SPA是最好的候选者，另外一方面，博客更适合MPA模型，由于博客渴望被搜索引擎抓取数据。虽然有不少工具可使SPA对于搜索引擎可见，可是目前的通常作法就是使用MPA。

最后

ABP平衡了一些最好的框架或者类库，除此以外，ABP本身的类和系统也提供了一个很好的用于N层架构Web应用构建的基础设施，也提供了很轻松地建立分层的解决方案的模板，用做应用的起点。

根据分层咱们把项目的类库用解决方案的文件夹整理下：