基于DDD的.NET开发框架-DDD经典分层

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

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

程序代码中也是响应的引用关系

各层概念：

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

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

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

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

领域模型的切割：

领域驱动设计除了对系统架构进行了分层描述，还对对象（Object）做了明确的职责和策略划分：

        、实体（Entities）：具备唯一ID，能够被持久化，具备业务逻辑，对应现实世界业务对象。
        、值对象（Value objects）：不具有唯一ID，由对象的属性描述，一般为内存中的临时对象，可以用来传递参数或对实体进行补充描述。
        、工厂（Factories）：主要用来创建实体，目前架构实践中一般采用IOC容器来实现工厂的功能。
        、仓库（Repositories）：用来管理实体的集合，封装持久化框架。
        、服务（Services）：为上层建筑提供可操作的接口，负责对领域对象进行调度和封装，同时可以对外提供各种形式的服务。

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

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

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

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应用构建的基础设施，也提供了很轻松地创建分层的解决方案的模板，用作应用的起点。

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

摘自：https://blog.csdn.net/orichisonic/article/details/51459709