000001_DDD领域建模知识分享
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
简单代码案例讲 解
Why DDD – 问题
开发：产品花太多时间调研，给我们太少时间开发 业务：怎么加这么小一个功能都要这么长时间 产品：你知道这个产品逻辑有多复杂？又是第一次，没人做过 测试：系统太复杂，来不及仔细测试 用户：这个产品稳定性怎么这么差 新来的开发：怎么文档都没有，我需要n周时间熟悉系统 领导：我只看结果，别给我找借口 老婆：你再996，我就离婚
限界上下文，领域和子域
限界上下文 • 是业务和语义的边界 领域 • 是问题域 核心域 • 企业的核心竞争力，需自建 支持域 • 具有企业特性，例如数据字典，可外包开发 通用域 • 没有企业特性的功能，可外购产品来构建能力
聚合
• 一个聚合包含一个或多个实体/值对象 • 一个聚合定义了一个数据一致性边界，例如：聚合内所以的实体保持事务的一致性 • 每个聚合都有一个聚合根和一个边界。 • 边界定义了聚合中应该包含什么。 • 每个聚合都有一个根实体，这个根实体做聚合根 • 聚合根是聚合中唯一允许被外部引用的元素，在聚合边界内，对象之间可以相互引用。 • 举个简单的例子，一个电脑包含硬盘、CPU、内存条等，这一个组合就是一个聚合，而电脑就是这个组合的聚合
根 • 聚合的特点：高内聚、低耦合，它是领域模型中最底层的边界，可以作为拆分微服务的最小单位，但我不建议你
对微服务过度拆分。但在对性能有极致要求的场景中，聚合可以独立作为一个微服务，以满足版本的高频发布和 极致的弹性伸缩能力。一个微服务可以包含多个聚合，聚合之间的边界是微服务内天然的逻辑边界。有了这个逻 辑边界，在微服务架构演进时就可以以聚合为单位进行拆分和组合了，微服务的架构演进也就不再是一件难事了。 • 聚合根的特点：聚合根是实体，有实体的特点，具有全局唯一标识，有独立的生命周期。一个聚合只有一个聚合 根，聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织和协调，聚合根与聚合根之间通过 ID 关联 的方式实现聚合之间的协同。
• 比如一个用户的Address为例，如果两个用户的地址是一样的。也就是说只要地址信息一样， 我们就认为是同一个地址。
新的开发模式
影响 UI
需求文档 PO（产品）
领域测试案例
领域专家（业务）
提供领域知识 验证模型结果
测试
Ubiquitous Language
领域模型 （代码）
实现领域 测试案例 （自动化）
开发
Agenda
01
什么是DDD？
05
基于微服务架构 构建旅程
02
为什么要使用 DDD？
06
DDD设计原则
03
• 实体的特点：有 ID 标识，通过 ID 判断相等性，ID 在聚合内唯一即可。状态可变，它依附于 聚合根，其生命周期由聚合根管理。实体一般会持久化，但与数据库持久化对象不一定是 一对一的关系。实体可以引用聚合内的聚合根、实体和值对象。
• 实体管理自己的属性和行为，并暴露行为
值对象
• 值对象的特点：无 ID，不可变，无生命周期，用完即扔。值对象之间通过属性值判断相等 性。它的核心本质是值，是一组概念完整的属性组成的集合，用于描述实体的状态和特征。 值对象尽量只引用值对象。
06
DDD设计原则
03
DDD核心概念
04
DDD需求分析、 设计、开发流程
07
DDD常用架构模式
08
简单代码案例讲 解
Evans DDD
2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计 ）简称Evans DDD
DDD 的核心知识体系，具体包括：领域、子域、核心域、通用域、支撑域、限界上下文、实体、值对 象、聚合和聚合根等概念。
Agenda
01
什么是DDD？
05
基于微服务架构 构建旅程
02
为什么要使用 DDD？
06
DDD设计原则
03
DDD核心概念
04
DDD需求分析、 设计、开发流程
07
DDD常用架构模式
08
DDD核心概念
04
DDD需求分析、 设计、开发流程
07
DDD常用架构模式
08
简单代码案例讲 解
领域驱动全景图
统一语言
统一语言是一个问题域里，所有相关人员所使用， 并且理解（不用再解释）的共同语言 • 产品、业务、开发、测试共用 • 每个问题域或限界上下文都有各自的通用语言。
同样的术语在各个领域里意义不一样
聚合中的不变性
• 不变性定义：无论何时数据发生变化，都必须满足所有一致变化的规则 ,俗话：同生死。 • 聚合内部的不变量必须在每次事务完成时满足。可以用仓储来实现。 • 一些依赖关系只能在某些特定的时刻通过事件借助有事务支持的服务来完成，或通过线程
安全模式实现原子操作。
实体
• 实体就是领域中需要唯一标识的领域概念。因为实体有生命周期，实体从被创建后可能会 被持久化到数据库，然后某个时候又会被取出来。
问题分析
业务到产品，只是分析，无设计的反馈 产品人员的设计没有技术实现作为实时反馈，导致错误百出 设计错误，加上沟通错误在下阶段的实现中被放大 设计的知识遗失
传统模式：
业务
产品
开发
解决方案 - DDD
业务、产品、开发一起 业务：领域专家，提供领域知识和验证软件实现 产品：协调沟通；提供功能、非功能需求；开发领域测试案例；UI设计 开发：与业务和产品一起开发统一语言，设计并实现领域模型
DDD 领域建模知识分享
Agenda
01
什么是DDD？
05
基于微服务架构 构建旅程
02
为什么要使用 DDD？
06
DDD设计原则
03
DDD核心概念
04
DDD需求分析、 设计、开发流程
07
DDD常用架构模式
08
简单代码案例讲 解
Agenda
01
什么是DDD？
05
基于微服务架构 构建旅程
来自百度文库02
为什么要使用 DDD？
领域建模是一种艺术的技术，它是用来解决复杂软件快速应付变化的解决之道
DDD是一种设计思想，它是基于事件风暴，使用通用语言，对业务进行领域建模，通过限界上下文对业务进行合理的领域拆
分，使得领域模型更好地转向微服务和落地，从而解决复杂系统难以理解，难以演进，也可以解决服务业务界限难以界定的问题。
战略设计 • 建立领域模型，划分服务边界，建立通用的限界上下文 战术设计 • 侧重于领域模型的实现，从领域模型转向微服务的设计和落地
Why DDD – 问题
开发：产品花太多时间调研，给我们太少时间开发 业务：怎么加这么小一个功能都要这么长时间 产品：你知道这个产品逻辑有多复杂？又是第一次，没人做过 测试：系统太复杂，来不及仔细测试 用户：这个产品稳定性怎么这么差 新来的开发：怎么文档都没有，我需要n周时间熟悉系统 领导：我只看结果，别给我找借口 老婆：你再996，我就离婚
限界上下文，领域和子域
限界上下文 • 是业务和语义的边界 领域 • 是问题域 核心域 • 企业的核心竞争力，需自建 支持域 • 具有企业特性，例如数据字典，可外包开发 通用域 • 没有企业特性的功能，可外购产品来构建能力
聚合
• 一个聚合包含一个或多个实体/值对象 • 一个聚合定义了一个数据一致性边界，例如：聚合内所以的实体保持事务的一致性 • 每个聚合都有一个聚合根和一个边界。 • 边界定义了聚合中应该包含什么。 • 每个聚合都有一个根实体，这个根实体做聚合根 • 聚合根是聚合中唯一允许被外部引用的元素，在聚合边界内，对象之间可以相互引用。 • 举个简单的例子，一个电脑包含硬盘、CPU、内存条等，这一个组合就是一个聚合，而电脑就是这个组合的聚合
根 • 聚合的特点：高内聚、低耦合，它是领域模型中最底层的边界，可以作为拆分微服务的最小单位，但我不建议你
对微服务过度拆分。但在对性能有极致要求的场景中，聚合可以独立作为一个微服务，以满足版本的高频发布和 极致的弹性伸缩能力。一个微服务可以包含多个聚合，聚合之间的边界是微服务内天然的逻辑边界。有了这个逻 辑边界，在微服务架构演进时就可以以聚合为单位进行拆分和组合了，微服务的架构演进也就不再是一件难事了。 • 聚合根的特点：聚合根是实体，有实体的特点，具有全局唯一标识，有独立的生命周期。一个聚合只有一个聚合 根，聚合根在聚合内对实体和值对象采用直接对象引用的方式进行组织和协调，聚合根与聚合根之间通过 ID 关联 的方式实现聚合之间的协同。
• 比如一个用户的Address为例，如果两个用户的地址是一样的。也就是说只要地址信息一样， 我们就认为是同一个地址。
新的开发模式
影响 UI
需求文档 PO（产品）
领域测试案例
领域专家（业务）
提供领域知识 验证模型结果
测试
Ubiquitous Language
领域模型 （代码）
实现领域 测试案例 （自动化）
开发
Agenda
01
什么是DDD？
05
基于微服务架构 构建旅程
02
为什么要使用 DDD？
06
DDD设计原则
03
• 实体的特点：有 ID 标识，通过 ID 判断相等性，ID 在聚合内唯一即可。状态可变，它依附于 聚合根，其生命周期由聚合根管理。实体一般会持久化，但与数据库持久化对象不一定是 一对一的关系。实体可以引用聚合内的聚合根、实体和值对象。
• 实体管理自己的属性和行为，并暴露行为
值对象
• 值对象的特点：无 ID，不可变，无生命周期，用完即扔。值对象之间通过属性值判断相等 性。它的核心本质是值，是一组概念完整的属性组成的集合，用于描述实体的状态和特征。 值对象尽量只引用值对象。
06
DDD设计原则
03
DDD核心概念
04
DDD需求分析、 设计、开发流程
07
DDD常用架构模式
08
简单代码案例讲 解
Evans DDD
2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计 ）简称Evans DDD
DDD 的核心知识体系，具体包括：领域、子域、核心域、通用域、支撑域、限界上下文、实体、值对 象、聚合和聚合根等概念。
Agenda
01
什么是DDD？
05
基于微服务架构 构建旅程
02
为什么要使用 DDD？
06
DDD设计原则
03
DDD核心概念
04
DDD需求分析、 设计、开发流程
07
DDD常用架构模式
08
DDD核心概念
04
DDD需求分析、 设计、开发流程
07
DDD常用架构模式
08
简单代码案例讲 解
领域驱动全景图
统一语言
统一语言是一个问题域里，所有相关人员所使用， 并且理解（不用再解释）的共同语言 • 产品、业务、开发、测试共用 • 每个问题域或限界上下文都有各自的通用语言。
同样的术语在各个领域里意义不一样
聚合中的不变性
• 不变性定义：无论何时数据发生变化，都必须满足所有一致变化的规则 ,俗话：同生死。 • 聚合内部的不变量必须在每次事务完成时满足。可以用仓储来实现。 • 一些依赖关系只能在某些特定的时刻通过事件借助有事务支持的服务来完成，或通过线程
安全模式实现原子操作。
实体
• 实体就是领域中需要唯一标识的领域概念。因为实体有生命周期，实体从被创建后可能会 被持久化到数据库，然后某个时候又会被取出来。
问题分析
业务到产品，只是分析，无设计的反馈 产品人员的设计没有技术实现作为实时反馈，导致错误百出 设计错误，加上沟通错误在下阶段的实现中被放大 设计的知识遗失
传统模式：
业务
产品
开发
解决方案 - DDD
业务、产品、开发一起 业务：领域专家，提供领域知识和验证软件实现 产品：协调沟通；提供功能、非功能需求；开发领域测试案例；UI设计 开发：与业务和产品一起开发统一语言，设计并实现领域模型
DDD 领域建模知识分享
Agenda
01
什么是DDD？
05
基于微服务架构 构建旅程
02
为什么要使用 DDD？
06
DDD设计原则
03
DDD核心概念
04
DDD需求分析、 设计、开发流程
07
DDD常用架构模式
08
简单代码案例讲 解
Agenda
01
什么是DDD？
05
基于微服务架构 构建旅程
来自百度文库02
为什么要使用 DDD？
领域建模是一种艺术的技术，它是用来解决复杂软件快速应付变化的解决之道
DDD是一种设计思想，它是基于事件风暴，使用通用语言，对业务进行领域建模，通过限界上下文对业务进行合理的领域拆
分，使得领域模型更好地转向微服务和落地，从而解决复杂系统难以理解，难以演进，也可以解决服务业务界限难以界定的问题。
战略设计 • 建立领域模型，划分服务边界，建立通用的限界上下文 战术设计 • 侧重于领域模型的实现，从领域模型转向微服务的设计和落地