领域驱动的微服务架构设计工作坊实施步骤

Posted 2021-04-14 北京设计模式学习组

事件风暴中各种报事贴之间的关系，源自Introducing EventStorming

致谢

本文参考了我的同事肖然、王威和刘尚奇于2017年7月22日在ThoughtWorks北京办公室所讲授的“领域驱动的微服务架构设计——实战工作坊”的课程内容，同时参考了我的同事亢江妹在业务分析工作中所使用的“拆分API故事”的实践方法，在此表示感谢。

目的

领域驱动的微服务架构设计工作坊，能使软件开发团队所有成员在短时间内，迅速就新产品或遗留系统的价值、用户画像、关键场景、聚合达成一致，以便让团队快速识别软件产品的问题域和解决方案域，发现微服务之间的API接口契约，并据此拆分微服务和团队，来开发新产品或重构遗留系统。对于不打算实践微服务的团队拆分模块也有参考意义。

步骤

准备

1）召集所有相关领域专家和开发团队成员（包括：业务分析、开发、测试、DBA等）参加工作坊，准备大白纸、6种颜色（深黄-Domain Event、深蓝-Command、深绿-aggregate、深粉-external system、紫-policy、浅黄-user）报事贴、蓝丁胶和黑色三福记号笔。

产品价值

2）一起创建用户画像（姓名、年龄、职业、居住地、问题、目标；所见、所听、所想和所感、痛点、目标）

3）用电梯演讲一起识别产品的核心卖点（差异化竞争优势）

关键场景

4）绘制用户旅程图，识别其中核心卖点的各个关键场景，并按时间顺序

5）选择核心卖点的第一个关键场景，画流程图

事件风暴

6）在流程图上贴值得记录日志的业务事件（深黄），并拍照

7）把事件移至流程图下方，并按时间排序

8）对每个事件贴命令（深蓝），对于一个命令触发多个事件的情况，只把命令贴在第一个事件处

9）在相关事件处贴该事件所触发的业务规则（紫）、该事件所源自的外部依赖系统（深粉），并在相关命令处贴该命令所源自的用户（浅黄）

聚合

10）在每个事件和命令之间贴聚合根（深绿），把具有相同生命周期（有助于维护业务一致性）和必须使用同步更新来实现数据完整性的聚合归并为同一聚合根之下，并为该聚合根取名

11）选择核心卖点的下一个关键场景，重复第5）～第10），直到识别并归并完所有的聚合

问题域和解决方案域

12）将各个聚合根据是否为业务核心卖点组织为子域，并识别核心子域、支撑子域和通用子域

13）将各个子域根据开发团队的约束条件组织为限界上下文（每个限界上下文可以作为一个微服务），并识别各个限界上下文之间的关系（partnership, shared kernel, customer-supplier, conformist, anti-corruption layer, open host service, published language），拍照

微服务之间的API接口契约

14）根据第6）步的拍照，复原流程图上的业务事件

15）在关键场景流程图下方，添加若干行，每一行贴一个深绿报事贴，代表一个相关的限界上下文

16）根据流程图上的每一个事件，识别相应限界上下文为实现该事件所应对外提供的接口，拍照

各个微服务内部的用户故事和验收条件

17）根据第13）步的拍照，复原聚合中的事件

18）根据限界上下文划分团队（这样划分的每个团队就是一个微服务团队），让各个微服务团队各自根据第13）步的拍照中的事件，编写用户故事和验收条件

19）各个微服务团队识别其所负责的限界上下文内部的名词（Aggregate Root, Entity, Value Object, Domain Events）和动词（Services），并绘制实体关系图，进行开发或重构

参考资料

[Domain-Driven Design](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215)

[《领域驱动设计》](https://item.jd.com/11961038.html)

[领域驱动的微服务架构设计——实战工作坊](http://www.10tiao.com/html/253/201706/2652457710/1.html)

[Domain-Driven Design Distilled](https://www.safaribooksonline.com/library/view/domain-driven-design-distilled/9780134593449/)

[Introducing EventStorming](https://leanpub.com/introducing_eventstorming)