构建领域驱动设计知识体系

1. 构建领域驱动设计知识体系张逸 http://zhangyi.xyz

2. 关于我架构编码实践者领域驱动设计布道师⼤数据平台架构师敏捷转型咨询师 @逸⾔

3. 01 AGENDA 领域驱动设计的历史回溯 ‣ ⾥程碑之⼀ ‣ ⾥程碑之⼆ ‣ ⾥程碑之三 ‣ ⾥程碑之四 03 领域驱动设计参考过程模型 02 对领域驱动设计的新定位 ‣ 领域驱动设计魔⽅ ‣ 丰富领域驱动设计⽅法 04 领域驱动设计能⼒评估模型

4. 01 领域驱动设计的历史回溯

5. ⾥程碑之⼀诞⽣ Domain-Driven Design Tackling Complexity in Software 2004年

6. ⾥程碑之⼆领域事件的引⼊

7. ⾥程碑之⼆领域事件的引⼊ Domain Event CQRS Event Sourcing Event Store EDA Reactive Programming Functional Programming

8. 建模范式的改变对象范式事件范式函数范式以“对象”为中⼼ Entity Value Object Aggregate Domain Service Repository Factory 以“事件”为中⼼ Domain Event Event Soucing Event Store Application Event Publisher-Subscriber 以“函数”为中⼼ Algebraic Data Type Pure Function Combinator Monad

9. 架构⻛格的改变对象范式事件范式函数范式分层架构事件驱动架构 CQRS 响应式架构

10. ⾥程碑之三微服务的引⼊ A microservices architecture puts each element of functionality into a seperate service and scales by distributing these services accross servers, replicating as needed.

11. 设计理念的改变数据模型驱动设计不适合微服务

12. ID AR AR ID 设计理念的改变 AR • 限界上下⽂的边界可以是微服务的边界 • 聚合的边界更加稳定，通过ID 引⽤聚合，有利于限界上下⽂边界的调整，改变通信⽅式 AR ID AR ID ID AR AR

13. UI M Q 设计理念的改变 domain DB domain ACL OHS ACL OHS domain domain ACL OHS domain • 维护好限界上下⽂边界，有利于从单体架构迁移到微服务架构

14. • 设计理念的改变领域模型与数据模型的分离，有利于从单体架构迁移到微服务架构

15. 领域驱动设计带来价值 • 领域驱动设计的模式与实践降低了从单体架构迁移到微服务架构的⻛险

16. 天作之合 Microservices Architecture Domain Driven Design

17. ⾥程碑之四中台战略的引⼊企业级能⼒复⽤平台 • 企业级：定义了中台的范围，区分开了单系统的服务化与微服务； • • • 能⼒：定义了中台的主要承载对象，能⼒的抽象解释了各种各样中台的存在；复⽤：定义了中台的核⼼价值；平台：定义了中台的主要形式。

18. Problem Space 企业级与能⼒ Solution Space Core Subdomain Core Subdomain Bounded Context Generic Subdomain Supporting Subdomain Bounded Context 核⼼⼦领域：企业核⼼价值 Bounded Context Bounded Context 限界上下⽂：业务能⼒

19. 领域模型的复⽤

20. 边界控制与平台沉淀

21. 探索…… ZhongTai Strategy ？ Domain Driven Design

22. 02 对领域驱动设计的新定位

23. 新的定位 Domain Driven Design Technology Philosophy

24. 件⼯ Z轴式模法⽅ X轴宏观层次领域驱动设计魔⽅ X轴：限定领域驱动设计的内容 Y轴：分离领域驱动设计的层次 Z轴：蕴含了领域驱动设计的实践微观层次纳⽶层次 Y轴业务技术管理

25. 宏观层次战略设计阶段宏观层次全局分析阶段宏观层次宏观层次是针对整个软件系统开展的战略宏图规划与战略概要设计，通常分为两个阶段： • 全局分析阶段 • 战略设计阶段业务全局分析⽂档业务战略设计⽂档架构全局分析⽂档核⼼领域业务架构限界上下⽂上下⽂映射需求管理体系整洁架构康威定律特性团队 RAID⻛暴业务精益需求管理技术管理⼯模⽅法微服务架构⻛格事件⻛暴件式架构战略设计⽂档发布计划 RUP 4+1视图业项⽬先启故事地图务件⼯ SCRUM 技式术管模理⽅法

26. 微观层次微观层次微观层次是承上启下的关键环节，是领域驱动设计在团队中落地的重要前提，这个层次输出的⼯件可以为团队成员提供直接的指导与参考价值。模型设计⽂档服务接⼝定义⽂档⻆⾊构造型事件⻛暴场景驱动设计分层架构迭代计划服务模型驱动设计业务⽤户故事看板件⼯ Scrum 技式术模管理⽅法

27. 纳⽶层次领域模型代码简单设计纳⽶层次纳⽶层次对应于软件开发过程的实现阶段。基础设施代码燃尽图燃烧图 ORM 事务处理测试驱动开发框架应⽤开发业务迭代实践件⼯ Scrum 技式术模管理⽅法

28. 引⼊ -业务架构业务架构（Business Architecture）呈现全⾯的、多维度的业务视⻆，包括：业务能⼒、端到端的价值交付、信息和组织结构，以及这些业务视⻆之间的关系，还包括它们与战略、产品、政策、项⽬和Stakeholder之间的关系。

29. 引⼊ -C4模型的 System Context 引⼊系统上下⽂（System Context）确定系统的边界，了解当前系统与利益相关⼈之间的关系，并确定它的外部环境，包括与其集成的第三⽅系统与基础设施。

30. 引⼊ -事件⻛暴

31. 引⼊ -架构模式

32. 引⼊ -RAID⻛暴

33. 引⼊ -RUP 4+1 视图领域驱动设计并没有明确给出架构的设计过程与设计交付物，限界上下⽂、分层架构、上下⽂映射仅仅作为战略设计的模式⽽存在。可以引⼊ RUP 4+1视图与领域驱动设计的战略设计结合。

34. 引⼊ -康威定律 Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

35. 引⼊ -精益需求管理与敏捷过程管理

36. 引⼊ -场景驱动设计与测试驱动开发

37. 引⼊ -测试策略领域驱动设计架构的每个逻辑层都定义了⾃⼰的控制边界，领域驱动设计的⻆⾊构造型位于不同层次。不同的设计元素，决定了它们不同的职责和设计的粒度。层次、职责和粒度的差异，恰好可以与测试策略形成⼀⼀对应的关系。

38. 03 领域驱动设计参考过程模型

39. 参考过程模型-固化与简化固化领域驱动设计的过程，提供简单有效的实践⽅法，建⽴具有⽬的性和可操作性的研发过程

40. 领域驱动设计参考过程模型全局分析阶段价值链 Value Stream 核⼼⼦领域 Core Subdomain C4模型 C4 Model 系统上下⽂ System Context ⻛险驱动设计 Risk Driven Design RAID Risks, Assupmtion, Issue, Dependency 精益需求管理 Lean Requirement Management 需求故事 Epic - Feature - User Story

41. 限界上下⽂ Bounded Context 事件⻛暴 Event Storming 领域驱动设计参考过程模型上下⽂映射 Context Map 事件流 Event Stream 战略设计阶段 RUP 4+1 架构视图 Architectural View 敏捷项⽬管理 Agile Project Management MVP & 故事地图 MVP & Story Map

42. 领域驱动设计参考过程模型领域模型驱动设计阶段迭代实践模式 Iteration Pratice Pattern User Story | Kick Oﬀ | Desk Check 事件⻛暴 Event Storming 领域分析模型 Domain Analysis Model 场景驱动设计 Scenario Driven Design 领域设计模型 Domain Design Model 测试驱动开发领域实现模型 Domain Implement Model

43. 04 领域驱动设计能⼒评估模型

44. 敏捷迭代能⼒能⼒评估模型介绍领域建模能⼒ DCAM 整洁编码能⼒领域驱动设计能⼒评估模型 Domain-driven design Capability Assesment Model， DMAM 架构设计能⼒ DCAM是⼀套评估模型，提供了对软件产品实施领域驱动设计的评估指标，指导团队进⾏能⼒的培养和提升。⽬前，DCAM仅限于对象范式的领域驱动设计。

45. DCAM并⾮⼀个标准或⼀套认证体系，更⾮事先制定和强制执⾏的评估框架。建⽴这套模型的⽬的仅仅是为了更好地实施领域驱动设计，它是⼀个能够不断演化的评估框架。能⼒评估模型介绍根据能⼒⽔平，分为三个等级层次。初始级成⻓级成熟级

46. 等级评估维度敏捷迭代能⼒团队需求过程初始级组件团队，缺乏定期的交流制度没有清晰的需求管理体系每个版本的开发周期⻓，⽆法快速响应需求的变化成⻓级全功能的特性团队，每⽇站⽴会议定义了产品待办项和迭代待办项采⽤了迭代开发，定期交付⼩版本成熟级⾃组织的特性团队，团队成员定期轮换，形成知识共享建⽴了故事地图、建⽴了史诗故事、特性与⽤户故事的需求体系建⽴了可视化的看板，由下游拉动需求的开发，消除浪费

47. 等级评估维度领域建模能⼒领域建模初始级采⽤数据建模，建⽴以数据表关系为基础的数据模型成⻓级采⽤领域建模，建模⼯作只限于少数资深技术⼈员，并凭借经验完成建模成熟级采⽤事件⻛暴、四⾊建模等建模⽅法，由领域专家与开发团队⼀起围绕核⼼⼦领域开展领域建模

48. 评估维度架构设计能⼒等级架构设计初始级采⽤传统三层架构，未遵循整洁架构，整个系统缺乏清晰的边界采⽤贫⾎领域模型，业务逻辑主要以事务脚本实现成⻓级领域层作为分层架构的独⽴⼀层，并为领域层划分了模块采⽤了富领域模型，遵循⾯向对象设计思想，但未明确定义聚合和资源库成熟级建⽴了系统层次与限界上下⽂层次的系统架构，遵循了整洁架构，建⽴了清晰的限界上下⽂与领域层边界建⽴了以聚合为核⼼的领域设计模型，职责合理地分配给聚合、资源库与领域服务

49. 等级评估维度整洁编码能⼒编码⾃动化测试初始级编码以实现功能为唯⼀⽬的没有任何⾃动化测试成⻓级⽅法和类的命名都遵循了统⼀语⾔，可读性⾼为核⼼的领域产品代码提供了单元测试成熟级采⽤测试驱动开发编写领域代码，遵循简单设计原则具有明确的测试战略，单元测试先⾏

50. 与我交流「逸⾔」公众号「TOP DDD」知识星球