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

目的

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

步骤

准备

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

事件风暴

产品价值

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

得到App的用户画像

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

得到App的电梯演讲

关键场景

4）绘制Use Case用例图，识别其中核心卖点用例（粉色）、支撑用例（橙色）和通用用例（白色，用例即用户目标），并按时间顺序；注意识别Ubiquitous Language（领域普通话）

得到系统用例

命令风暴

5）选择第一个核心卖点用例，按从左往右的顺序用贴深蓝报事贴的方式画流程图，图中每一步都是值得“埋点”的命令（深蓝）

“查看已购产品”流程图

事件风暴

6）在流程图上贴值得记录日志的业务事件（深黄，有可能一个命令触发多个事件，每个事件单独写一个报事贴）

在流程图上贴深黄的业务事件

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

在相关事件处贴该事件所触发的紫色的业务规则

聚合

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

把聚合归并到聚合根之内

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

问题域和解决方案域

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

粉红背景的是核心子域，橙色背景的是支撑子域

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

识别限界上下文之间的关系

微服务之间的API接口契约

12）在关键场景流程图下方，添加若干行，每一行贴一个深绿报事贴，代表一个相关的限界上下文
13）根据流程图上的每一个事件，识别相应限界上下文为实现该事件所应对外提供的接口，拍照

API接口契约

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

14）根据限界上下文划分团队（这样划分的每个团队就是一个微服务团队），让各个微服务团队各自根据流程图中所负责的事件，编写用户故事和验收条件
15）各个微服务团队识别其所负责的限界上下文内部的名词（Aggregate Root, Entity, Value Object, Domain Events）和动词（Services），并绘制实体关系图，进行开发或重构

参考资料：

Domain-Driven Design
《领域驱动设计》
领域驱动的微服务架构设计——实战工作坊
Domain-Driven Design Distilled
Introducing EventStorming