ABP-VNext 专题 基础-----浅出DDD 领域驱动设计11.8更新

1.DDD核心机制理解

领域驱动设计 从业务角度来处理===》业务需求驱动设计

业务需求：一个系统需要解决的问题

例如电商场景下：

公司-----开发---》电商系统----解决--->卖商品的问题

所以核心根本业务需求 就是 卖商品

2.DDD应用场景

业务需求如何设计成业务  那就要根据核心业务 商品 进行设计 和商品有关的 组合起来 就叫做 商品领域

通过商品领域 来设计我们的系统   也就是 领域驱动设计  我觉得更可以认为是 业务驱动设计 业务的产生使得 领域的产生

结论：1.每一个系统背后总有一个业务存在  这个业务分为两类 第一：关于人第二：关于系统的问题 

           2. 为什么要这样设计：为了解决系统复杂性上升的问题 -------》例如一套系统对应很多种客户端 

3.DDD分层架构及原理

解决复杂性问题主要靠 DDD的分层架构：如图

 

 DDD架构层次：

1.领域层：商品领域

2.应用层：客户端UI调用层

3.展现层：客户端UI

4.基础设施层：支持以上三层的一些基础功能

传统三层架构 比较DDD：UI  BLL DAL DB

当传统三层Web需要扩展适配移动端设备时 如果此时需求只想展示商品的其中的几个或者多个属性 我们在扩展UI界面的同时也要同时修改BLL的商品逻辑 如果我们需要扩展很多个客户端 那我们需要对BLL进行多次修改 对系统的稳定性是一个巨大影响 违背了开闭原则

如何适应客户端的各种需求 所以我们再次基础上扩展出 商品应用层 Web商品对应商品应用层  移动端对应移动端对应相应的商品应用层 此处只是对 商品应用层的扩展  达到了四层  BLL层独立抽取出来形成领域层 并且不仅仅局限于 业务逻辑

4.DDD领域模型

5.DDD实战落地

.NET5落地

DoMain：整个项目的根-->驱动整个项目的设计

商品领域;商品

1.实体（Entity）:商品基本的描述

2.聚合（Aggregate）和聚合根（Aggregate Root）：聚合 ：商品与商品相关的所有信息 形成聚合  聚合根：相对而言 通过根获取根下的所有信息

3：仓储（Repository）（接口）：客户端输入将领域对象   存储到所需的数据库

4.领域服务（Domain Service）:如果像修改 实体中的某个属性 就靠领域服务

5:领域事件（Domian Event）：更新实体时性能低时 使用异步更新 将需要更新的字段发给 领域事件----解决各个领域之间交互的问题（同步 或异步） 实现：发布订阅 消息队列 

6.值对象（value Object）：不变的对象 值对象=值+对象=将一个值用对象的方式进行表述，来表达一个具体的固定不变的概念。

7：规约(Specification)：对实体的过滤 

1 .对于单实体进行规定约束。主要针对属性
 2、对于集合实体进行规定约束。主要针对集合过滤

总结：任何系统 都是任何业务需求的关系

例如：电商系统中  人和商品的关系

Application：接收UI 请求 UI层的增加导致应用层 这些应用层都依赖领域层 这就是 领域驱动设计

EntityFrameWorkcore：数据迁移

Web：通过应用层 访问领域

总结：

DDD解决了客户端复杂性的问题：当你的系统需要WEB 移动端 小程序时 使用DDD。通过不同的DTO应用层+业务逻辑 实现  DDD的核心就是以业务需求作为驱动  通过传统三层的比较 你会发现传统三层 面对客户端需求增多时 需要不断修改业务逻辑层BLL 这样会造成系统稳定性的极大破坏 违背了系统开发的 开闭原则  从此 在BLL之上扩展出应用层 应对不同的UI客户端 逻辑层并没有发生改变 ，在DDD种中 我们是根据业务 就是领域作为驱动 以他为根 展开 也就是领域模型 ；

如何系统抽象出来 都是人和业务的关系 例如 电商中 是 任何商品的关系

UI调用 应用层 调用 Domain 调用 DB