DDD（Domain Driver Design）领域驱动设计

DDD是什么？

DDD是领域驱动设计，是一种软件开发方法，旨在通过使用领域模型来简化软件的开发、测试和维护。

落地方式

战略和战术设计

四色建模法

• 业务关键时刻
• 角色
• 人-事-物
• 概述

用例分析法

事件风暴法

领域故事讲述法

战略设计

三步骤 1.在事件风暴中梳理业务中的用户操作，事件，以及外部依赖，根据这些要素梳理领域实体对象 2.根据领域实体间的业务关联性，将业务紧密相关的实体组合成聚合，同时确定聚合中的聚合根，值对象和实体，聚合之间的边界就是第一层边界，逻辑边界。 3.根据业务以及语义，将一个或多个聚合划定在一个限界上下文，形成领域模型。限界上下文之间的边界是第二层边界，可能就是微服务的边界，物理边界。

• 参与人员
  • 业务专家（领域专家）
  • 产品经理
  • 技术专家（研发人员）
• 官方-白话解释
  • 官方：在某个领域，核心围绕上下文的设计。主要关注上下文的划分，上下文映射的设计，通用语言的定义
    • 上下文划分Bounded Context
    • 上下文切换Context Map
    • 上下文通用语言Ubiquitous Language
  • 白话解释：在某个系统，核心围绕子系统的设计。主要关注系统的划分，系统内的核心术语定义
    • 系统划分
    • 交互方式
    • 系统内的核心术语
• 领域+子域+核心域+通用域+支撑域
  • 领域
    • 领域是用来确定范围的，范围即边界，与微服务建设过程方法基本类似，核心思想就是将问题域逐步分解，降低业务系统实现的复杂度
  • 子域
    • 领域进一步划分的多个子领域，每个子域对应一个更小的问题域或更小的业务范围
  • 核心域
    • 决定产品和公司核心竞争力的子域
  • 通用域
    • 没有太多个性化的诉求，同时被多个子域使用的通用功能子域
  • 支撑域
    • 既不包含核心竞争力，也不包含通用功能的子域，例如数据代码类的数据字典
• 限界上下文+定义领域边界
  • 1.通用语言
  • 2.限界上下文
    • 限界就是领域的边界，上下文则是语义环境，用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语，业务相关对象有一个确切的含义，没有二义性。理论上限界上下文就是微服务边界。

战术设计

• 参与人员
  • 技术专家（研发人员）
• 官方-白话解释

  • 官方：核心关注上下文中的实体建模，定义值对象，实体等，更偏向开发细节。 VO Entity Aggregate

    实体 聚合 聚合根 值对象 聚合之间的关系

    仓库 工厂 防腐层 充血模型 领域服务 领域事件

  • 核心关注某个子系统的代码实现，以面向对象的思维设计类的属性和方法，将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构绑定

• 实现方式（为了高内聚，低耦合）
  • DDD分层架构
    • 聚合之间的代码边界一定要清晰
    • 一定要有代码分层的概念
  • 整洁架构
  • CQRS
  • 六边形架构
• 实体
  • 具有唯一标识，通常和数据库表对应。多个属性，操作或行为的载体。实体和值对象会形成聚合，每个聚合一般在一个事务中操作，一般持久性。
• 值对象
  • 不关心唯一值，具有校验逻辑，等值判断，只关心值的类，值对象本质就是一个集
• 聚合根
  • 软件模型中那些以名词形式存在的领域对象。聚合根是主要业务的逻辑载体，DDD中所有的战术实现都围绕聚合根展开，70%场景下一个聚合内都只有一个实体，那就是聚合根。 说白了，聚合的根实体，最具有代表性的实体。比如订单和订单项聚合之后的聚合根就是订单。
  • 特征
    • 1.它作为实体本身，拥有实体的属性和业务行为，实现自身的业务逻辑
    • 2.它作为聚合的管理者，在聚合内部负责协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑
    • 3.聚合根之间的引用通过ID完成。聚合之间通过聚合根ID关联引用，如果要访问它聚合的实体，要先访问聚合根，再导航到聚合内部实体。
• 聚合，聚合根，实体，值对象对比
  •