DDD的理解及实践探讨

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. DDD的理解及实践探讨 熊锐 2022-08
2. 主要内容 • 领域驱动设计概述 • 几个概念的理解 • 几个实践问题的探讨
3. 为什么领域驱动设计 领域驱动设计 ²一种思维方式:关注点从工具回归到问题域本身 ²一组优先任务:以业务为先导 ²一种软件开发方法:系统拆解和集成方法、建模方法、分层架构、实现工具集
4. 如何领域驱动设计
5. 战略设计- 统一语言 ²定义 : 提炼领域知识的产出物,体现在两个方面,1)统一的领域术语,2)领域行为描述 ²如何获取 : 统一语言就是需求分析的过程,也是团队中各个角色就系统目标、范围与具体功能达成一致的过程 ²强调统一: 无论是与领域专家的讨论,还是最终的实现代码,都使用相同的术语 ²强调约束: 既要有内涵也要有外延
6. 战略设计- 子域和限界上下文 总体设计思路:分治,避免大泥球 ²子域划分:确定逻辑边界 ²核心域:重点关注,重点资源投入 ²支撑域:专注于业务的某个方面 ²通用域:用于整个业务系统 ²限界上下文:确定物理边界 ²边界内概念含义统一 ²不同边界内概念的关注点不同 D ²包含领域模型&系统实现 ²上下文映射图:集成 ²九种映射关系 u 过程管理 上下文 D 资源管理 上下文 u D u 运营管理 上下文 u D 数据管理 上下文
7. 战术设计- 设计过程 总体设计思路:面向对象 概念建模 问题、业务、抽象 领域建模 框架设计 解决、技术、具体
8. 战术设计- 框架设计 总体设计思路:分层、CQRS、EDA
9. 主要内容 • 领域驱动设计概述 • 几个概念的理解 • 几个实践问题的探讨
10. 复杂度 Jurgen Appelo 从理解力与预测能力两个维度分析了复杂系统理论 规模 理解力 结构 复杂度 预测能力 复杂的成因 复杂的控制 规模 分解 结构 层次结构 变化 抽象 变化
11. 复杂度 复杂的控制方法在领域驱动设计中的体现 子域划分 限界上下文 抽象 上下文映射图 领域建模 分解 分层架构 CQRS 事件驱动 层次结构
12. 领域&领域驱动- 为什么是“领域驱动” • 领域 ²含糊定义:一个组织所做的事情以及其中所包含的一 切(和“业务”的区别?) • 领域驱动 关注点由技术转向业务(问题) 以业务为先导(问题) ²问题+边界+知识 业务角色参与设计(问题) ²问题:具体业务目标 ²边界:范围的 ²知识:行业的,固定模式,内在规律 统一语言(知识) 划分子域(知识) 限界上下文(边界) 面向对象建模(问题、知识) 以上设计原则是对领域的回应,所以是领域驱动设计
13. 子域&限界上下文&微服务 限界上下文:不在于如何划分边界,而在于如何控制边界 Ø 领域逻辑层面:限界上下文确定了领域模型的业务边界 Ø 团队合作层面:限界上下文确定了开发团队的工作边界,建立了团队之间的合作模式 Ø 技术实现层面:限界上下文确定了系统架构的应用边界,保证了系统层和上下文领域层各自的一致性 子域 问题 N 1 限界上下文 桥梁 1 N 微服务 解决 ²限界上下文代表语义边界,所以逻辑层面可能多个子域在一个限界上下文内 ²从业务视角看通常一个限界上下文对应一个微服务,但考虑技术因素情况下可能对应多个服务 ²考虑高性能和稳定,一般将核心流程和非核心流程分离:query服务、offline服务、job服务
14. 模型 ²模型:抽象知识的表达 ²模型长什么样子 ²抽象:非具体细节的 ²不同的描述目的和描述对象会有不同模型 ²知识:基本规律 ²可以UML图、类图、DDD领域建模语 ²表达:描述和传达知识 言、代码与文档 ²领域模型是领域驱动设计的核心,也是从问题到解决的桥梁: 认识-传达-指导开发
15. 战术设计工具集 ²值对象 ²可度量、不变性、相等性 ²直观表现是没有id ²通常为度量单位、枚举等,比如币种、行政区等级 ²领域服务 ²是服务,不适合放在单个聚合和对象上的操作 ²是领域的,非应用服务 ²通常一个领域的计算/转换过程,或由多个领域对象协作产 生的能力 ²比如利率计息算法、逾期等级计算方法 ²聚合根 ²满足对象操作的业务一致性规则
16. 主要内容 • 领域驱动设计概述 • 几个概念的理解 • 几个实践问题的探讨
17. 划分领域 ²业务本源 ²一个常见的模式:纵+横 ²依据于业务的本质 ²纵:根据业务目标和价值垂直划分 ²根据目标、价值、维度划分 ²横:共性能力提取,划分通用域和支撑域 ²参考行业 ²相对成熟的领域:电商、金融、HR、财务…… ²参考业务对象(端) ²业务的直接表象 ²B端:CRM、SCP…… ²C端:交易、履约…… ²M端:运营、财务…… ²参考业务组织 ²康威定律
18. 领域服务 & 应用服务 ²战略层语境: ²战术层语境: ²领域服务通常指相对聚焦的底层支撑域/通用域服务 ²领域服务指领域建模工具集中所指的“领域服务” ²应用服务通常指面向业务场景负责功能组装的服务 ²应用服务指面向场景的技术实现组装 ²在战术层语境,应用和领域仅仅是技术和业务的分离吗?能否参考战略层语境?
19. 领域服务 & 应用服务 信贷领域记账的场景例子 全额还款 财务还款 还款金额试算和校验 减免输入利息 隔日记账校验减免 减免输入罚息 计划缩期 还款冲抵 全额还款 逻辑的场景 相关性 还款金额试算和校验 减免输入利息 隔日记账校验减免 减免输入罚息 计划缩期 还款冲抵 生成状态转移 结清借据 还款冲抵 生成动账 生成动账 生成动账 财务还款 生成状态转移 生成状态转移 应用服务 • 场景相关的 • 相对易变的 领域服务(行为) • 场景无关的 • 相对稳固的 • 可复用的 结清借据 结清借据 ²战术层语境,应用服务可否包含面向场景的业务逻辑的组装?
20. 领域层再分 ²场景:多业务线&多产品,业务共性较多,但也存在部分差异 CRM领域不同业务线的资源管理 信贷领域各类产品 业务线 业务线A 业务线B 业务线C 资源范围 品类A全国 品类B31城 全品类全国 划分方式 地理单元划分 行政城市方式划分 自定义 管理单元 地理单元 城市(北京朝阳) 地理单元 组织 业务线A销售组织 业务线B销售组织 业务线A+C销售组织 信用贷 信用付 经营贷 组织和管理 单元 组织最底层节点对应管 理单元 组织最底层节点对应管理 单元 组织最底层节点对应管理 单元 私海 BD所属资源,唯一 BD所属资源,唯一 BD所属资源,唯一
21. 领域层再分 ²方案:平台化思路,避免垂直烟囱,提人效降成本 ²问题:多业务/多产品带来领域的复杂 ①抽象建模:抽象共性,泛化概念 ②分离变化:分离抽象和具体 ③分层的演进:领域实现层
22. 富血对象落地的问题 ① 富血对象和spring依赖注入 ②大聚合根和性能问题 ③领域对象存储性能问题:增 or 删 or 改? ——BeanHolder静态方法 ——懒加载+SPI模式 ——根据业务逻辑判断,有侵入 ——难以做到去spring ——难以做到去spring ——通过领域对象修改前后的比对判断
23. DDD对clean code的再定义
24. 参考资料 [1] 《领域驱动设计》 Eric Evans [2] 《实现领域驱动设计》Vaughn Vernon [3] 《领域驱动设计实践(战略+战术)》 张逸 [4] 《面向对象分析与设计》 Grady Booth,Kobert A. Maksimchuk等 [5] 《大象 Thinking in UML》 谭云杰 [6] https://ipu.sankuai.com/ipu/courseware-detail/44800/3071 [7] https://ipu.sankuai.com/ipu/courseware-detail/47340/4407
25. Q&A
26. 招聘: 美团金融-资深Java技术专家 美团金融-支付架构师 邮箱:cuiyuanyuan02@meituan.com 更多技术干货 欢迎关注“美团技术团队”

Home - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-17 18:49
浙ICP备14020137号-1 $Map of visitor$