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

领域驱动架构设计详细讲解（⼀）
⼀、什么是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相关的理论知识就介绍到这⾥，在下⼀篇我将结合实例来和⼤家进⾏进⼀步的学习。