领域驱动架构设计详细讲解（一）

 一、什么是DDD？

       DDD又叫领域驱动设计，它是一种软件开发的思想，不是具体的技术或者框架，它的核心是维护一个能够反映领域概念的模型，通过一些模式和约束来指导团队进行统一的设计开发。  

二、为什么要使用DDD？

• 从技术层面进行分层，每层都在关注自己的事情，比如领域层关注业务逻辑，仓储层关注持久化数据，应用服务层关注协调领域层和仓储层实现某一个业务，接口层关注暴露应用服务接口给外界调用
• 从业务维度，将大的系统划分为多个领域界限，可以选择将不同的界限分配给不同的团队、不同的界限使用不同的仓储，实现界限内是高内聚而界限之间是低耦合的

由于DDD只是一种开发理念，所以要想在项目中发挥他的作用，我们需要先搞懂它里面的一些基本概念和核心组件，然后基于它搭建一个轻量级的框架。 

三、DDD的核心组件

1.领域界限：

对于一个系统而言，我们对其按照不同的领域划分不同的界限，不同的领域界限之间可以是相互独立的。每个领域内都有自己独立的领域逻辑、数据持久化和接口等。

2.聚合的概念：

通常我们会将多个实体和值对象进行组合来表达一个完整的概念，比如订单实体、订单详情实体、订单收货信息组成了一个完整的订单概念，他们的生命周期是一样的，在进行持久化时也应该进行统一持久化。

3.聚合根的概念：

对于一个聚合而言，必须有一个对象能够表达这个聚合的总概念，外界想要对这个聚合进行持久化的操作时，必须通过这个总概念进行协调，通过它来保证业务一致性，那么这个对象我们就称之为聚合根。

在一个聚合中有且只有一个聚合根，想要访问聚合内的对象，必须要通过聚合根才能进行访问（当然，其他的实体可以在外界需要查询时临时调用），聚合根拥有唯一的标识，也拥有业务生命周期，其本质也是实体。比如订单聚合中的订单实体即为这个聚合的聚合根。

4.实体的概念：

实体是一个有业务生命周期的概念，拥有唯一标识用于标识和区分。比如一个订单对象就是一个实体。

5.值对象的概念：

值对象是一个无业务生命周期的概念，通常用于定义聚合中的某一个复杂的对象属性，不需要定义标识进行区分。比如一个订单中的收货信息。

6.仓储的概念：

仓储用于对聚合进行持久化，通常情况下我们为聚合内的聚合根配备一个仓储即可 。

有了上面这些核心概念之后，下面我们看看搭建一个DDD的架构需要做什么

四、经典DDD架构：

1.基础结构层

定义DDD框架的底层基本概念，需要实现：聚合根接口定义(IAggregationRoot)、实体接口定义(IEntity)、值对象接口定义(IValueObject)、基本仓储接口定义(IRepository<T>)和仓储接口的持久化实现(EFCoreRepository<T>)

定义顶层的聚合根仓储具体实现，继承自基本仓储接口实现和聚合根的仓储接口，实现基本仓储接口内的用于公共仓储使用的方法

2.领域层：界限上下文的领域逻辑

需要定义界限上下文的领域对象的POCO模型，在模型中也可以定义自己的业务逻辑，业务逻辑不要与仓储发生直接接触

定义领域内聚合根的仓储接口，该接口继承自基础结构层的基本仓储接口，聚合根的仓储接口可定义自己的业务接口

定义领域内的仓储接口的实现，继承自基本仓储接口及顶层仓储实现

3.应用服务层：领域对外公布接口的业务实现。

通过调用领域对象的领域逻辑，完成领域的逻辑业务。

通过调用聚合根的仓储接口完成对领域对象的预持久化（此时的数据保存在数据库上下文中）

通过调用基础仓储接口层的工作单元方式进行数据的提交完成真正的持久化（此时在上下文中做更改的数据将被一起保存到数据库）

比如用户下订单之后，系统需要创建订单、扣减库存、增加用户积分等等，在订单的应用服务内需要调用订单领域内的领域对象逻辑和仓储并协调库存仓储和用户仓储一起完成

4.接口层：非常薄的一层

定义外界访问的接口，调用应用服务层的实现完成某一业务动作

 

对于DDD相关的理论知识就介绍到这里，在下一篇我将结合实例来和大家进行进一步的学习