领域驱动设计

“Domain-Driven Design领域驱动设计”简称DDD，是一套综合软件系统分析和设计的面向对象建模方法，想要了解的小伙伴记得收藏哦！

领域驱动设计，知识点梳理

• 1.领域驱动设计基础
  • 领域驱动设计的特点
    • 发现问题和理解问题
    • 领域即边界
      • 边界靠分类
        • 分类需要从内外部外入手
      • 菠萝在水果店，属于水果；菠萝在菜谱上属于食材
    • 解决复杂性
  • 领域驱动设计的难点
    • 业务策略、业务规则
    • 领域模型提炼
      • 呈现方式
        • UML符号
        • 流程图
        • 类
        • 数据结构
        • 算法
      • 要点
        • 1）简单准确。模型是对真实事物的简化理解，注意力需要集中在内部要点上。
        • 2）通用统一。语言必须足够通用，应该是业务人员的务实术语，能够提供人们在谈论系统时可以使用的统一语言。
        • 3）逻辑严格。逻辑上必须足够严格，从而可以成为编写代码的基础。
• 2.领域驱动战略设计
  • 2.1有界上下文
    • 发现有界上下文
      • 头脑风暴、、分析现有文档
    • 头脑风暴、分析现有文档
      • 过程方法
        • 画图
          • • 一个有界
              • 两个有界
        • 领域专家创建词汇表
      • 有分歧必较真
      • 目标
        • 提出更好、更精准、更通用的统一语言
        • 发现有界上下文
        • 发现业务规则
          • 理清业务规则
  • 2.2有界上下文划分方法
    • 按时间线
      • 分析方法
        • UML图
          • 时序图
          • 用例图
          • 类图
        • 商品为例
          • 商品组件
            • 提从商品操作功能的组件
              • 商品服务组件
                • 只有商品，则是仓储
                • 有服务的存在，才有商品的应用场景，即商品的应和上下文
    • 通过领域故事或流程
      • 开普勒主prd
    • 通过事件风暴会议
      • 事件
        • 关系（动宾）
          • 事实（被动语句）
            • 关系与事实表达方式
              • 谁放首位，隐含当前边界主人
                • 发现有界上下文
        • 事件即关系
        • 用例场景：用户挑选自己喜欢的商品，将它放入购物车，用户确认生成订单，并进行支储，商家根据订单发货，用户收到货后确认收货
      • 命令
        • 事件发生是有原因的
          • 引入命令
        • 命令
          • 触发事件
      • 命令与事件区别
        • 订阅模型
• 3.聚合
  • 组成
    • 实体
      • 一个实体模型就是一个独立的事物。每个实体都拥有一个唯一的标识符，可以将它的个体性和所有其他类型相同或者不同的实体区分开
      • 一个聚合根可有多个实体组成，其中一个实体被称为聚合根
      • 聚合根推荐使用工厂模式+Builder模式组合使用，但是如果聚合对象为实体自聚合还是构造方法、builder均可
    • 值对象
      • 是对一个不变的概念整体所建立的模型。在这个模型中，值就真的只有一个值。和实体不一样，它没有唯一标识符，而是由值类型封装的属性对比来决定相等性。
      • 值对象(VO)与数据传输对象(DTO)的区别
        • 值对象一旦创建，就不改变，如需改变里面的值，需要重新创建
          • 值对象字段推荐用final关键词修饰
        • DTO 可变数据容器，可修改，使用DTO做数据库存储时，不确定哪个节点变更了，问题不易排查
          • 推荐
            • 尽可能的使用VO处理业务逻辑内部数据传递
              • 我们大多数DTO都是不停的在clone,没有修改
            • 存储层入参需是 聚合对象、实体、值对象
    • 行为
      • 商品聚合
        • 添加sku
        • 添加类目
        • 添加商品图片
  • 3.聚合设计
    • 设计原则
      • 高聚合低关联
        • 聚合内部对象在数据和行为上高度关联和一致，除此之外关系就抛弃
        • 商品与类目业务分析 可升级为强关联
        • 缺少订单条目的订单不能为为订单
      • 迪米特法则（最少知道原则）
        • 初衷：降低类之间的耦合
          • 实现方式
            • 方法参数为对象（springBean)
            • applicationContext中获取
    • 经验法则
      • 在聚合边界内保护业务规则不变性
        • 当所有Task实例的hoursRemaining都为零时，BacklogItem的状态必须设置为DONE。”因此，当事务完成提交时，这项特定的业务不变性规则必须要满足。这是业务要求的
      • 聚合要设计得小巧（单一职责）
        • • 拆分
      • 只能通过标识符引用其它聚合
      • 利用最终一致性更新其它聚合
    • 实现逻辑一致性
      • 结构关系（高聚合低关联设计）
      • 行为动作
      • 事务实现
    • 聚合根设计方法
      • 更换主谓宾顺序
        • 用户正在订购一本书
        • 一本书是由用户订购
        • 一本书的订单被用户下了
      • 根据领域事件
        • 医生开处方
          • 参与者：医生、病情、患者、处方
          • 命令：医生开具处方
          • 事实：处方开了
      • 通过职责行为
        • 信息拥有者模型
        • 决策控制者模型
          • 聚合
            • 决策者
          • 服务模型
            • 协作者
              • 传递做决策的职责
          • 子主题
      • 通过事务边界
      • 按时间边界
• 4.领域服务
  • 特点
    • 行为无法放入某个实体或值对象的行为，或者涉及多个实体与值对象的行为
      • ProductFactory创建商品
      • 聚合根设置类目，sku
      • 调用Facade调用中台创建商品
      • 调用存储层写入库
      • 派发商品创建成功事件
      • 服务协作者
    • 出入参可能非实体及值对象
    • 行为必须是无状态的
• 5.仓储
  • 数据持久化
    • ES
    • 缓存
    • DB
• 6.架构设计
  • 清洁架构
  • 六边形架构
    • 特点
      • 在六边形里面是所有的业务模式/逻辑，外面则是基础设施，也就是代表所有技术规范。
      • 依赖关系始终从外部进入内部，这确保了业务域的隔离，如果以后更改基础架构，业务逻辑将可以重用
    • 好处
      • 将对业务逻辑的关注和对技术架构的关注实现分离，两者可通过控制反转IOC模式联系在一起，当然发布/订阅等模式在解耦程度上更高些。
  • 垂直切分架构(单一职责)

讨论问题

• 聚合
  • 聚合对象行为方法是否包含jsf接口方法及数据库持久化动作（及包含facade,仓储的调用），
    • 例:商品聚合根-发布商品 通过回调接口或函数式接口的方式，包含 商品中台发面商品商品，本地写库功能
  • 聚合对象中值对象初始化方式
    • 来源当前域
    • 来源（支撑域，通用域）
• 存储
  • 存储层定义粒度
    • 简单实体粒度
    • 聚合根粒度
  • 存储层逻辑如何做到化繁为简
• 领域服务到底承接哪些工作

商品中台DDD实践