产品愿景是对产品的顶层价值设计，对产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。建议参与角色：业务需求方、产品经理和开发组长。
2、场景分析
场景分析是从用户视角出发，探索业务领域中的典型场景，产出领域中需要支撑的场景分类、用例操作以及不同子域之间的依赖关系，用以支撑领域建模。 建议参与角色：产品经理、需求分析人员、架构师、开发组长和测试组长。
3、领域建模
领域建模是通过对业务和问题域进行分析，建立领域模型，向上通过限界上下文指��微服务边界设计，向下通过聚合指导实体的对象设计。 建议参与角色：领域专家、产品经理、需求分析人员、架构师、开发组长和测试组长。
4、微服务拆分和设计
结合业务限界上下文与技术因素，对服务的粒度、分层、边界划分、依赖关系和集成关系进行梳理，完成微服务拆分和设计。 微服务设计应综合考虑业务职责单一、敏态与稳态业务分离、非功能性需求（如弹性伸缩要求、安全性等要求）、团队组织和沟通效率、软件包大小以及技术异构等因素。 建议参与角色：产品经理、需求分析人员、架构师、开发组长和测试组长。
领域对象及服务矩阵和代码模型设计¶本阶段完成领域对象及服务矩阵文档以及微服务代码模型设计。
1、领域对象及服务矩阵
根据事件风暴过程领域对象和关系，对产出的限界上下文、聚合、实体、值对象、仓储、事件、应用服务、领域服务等领域对象以及各对象之间的依赖关系进行梳理，确定各对象在分层架构中的位置和依赖关系，建立领域对象分层架构视图，为每个领域对象建立与代码模型对象的一一映射。 建议参与角色：架构师和开发组长。
2、微服务代码模型
根据领域对象在 DDD 分层架构中所在的层、领域类型、与代码对象的映射关系，定义领域对象在微服务代码模型中的包、类和方法名称等，设计微服务工程的代码层级和代码结构，明确各层间的调用关系。 建议参与角色：架构师和开发组长。
领域对象及服务矩阵样例说明¶领域对象及服务矩阵主要用来记录事件风暴和微服务设计过程中产出的领域对象属性，如：各领域对象在 DDD 分层架构中的位置、属性、依赖关系以及与代码对象的映射关系等。通过建立领域对象与代码对象的映射关系，可指导软件开发人员准确无误的按照设计文档完成微服务开发。 以下为领域对象及服务矩阵样例（部分数据，仅供参考）。
各栏说明如下： * 层：
定义领域对象位于 DDD 分层架构中的哪一层。如：接口层、应用层、领域层以及基础层等。
聚合：
在事件风暴过程中将关联紧密的实体和值对象等组合形成聚合。本栏说明聚合名称。 * 领域对象名称：
领域模型中领域对象的具体名称。如：“请假审批已通过”是类型为“事件”的领域对象；“请假单”是领域类型为“实体”的领域对象。
领域类型：
在领域模型中根据 DDD 知识域定义的领域对象的类型，如：限界上下文、聚合、聚合根（实体）、实体、值对象、事件、命令、应用服务、领域服务和仓储服务等。 依赖对象名称：根据业务对象依赖或分层调用依赖关系建立的领域对象的依赖关系（如服务调用依赖、关联对象聚合等）。本栏说明领域对象需依赖的其他领域对象，如上层服务在组合和编排过程中对下层服务的调用依赖、实体之间或者实体与值对象在聚合内的依赖等。
包名：
代码模型中的包名，本栏说明领域对象所在的软件包。
类名：
代码模型中的类名，本栏说明领域对象的类名。
方法名：
代码模型中的方法名，本栏说明领域对象实现或操作的方法名。
微服务代码结构模型¶微服务代码模型最终结果来源于领域对象及服务矩阵。在代码模型设计时须建立领域对象和代码对象的一一映射，保证业务模型与代码模型的一致性，即使不熟悉业务的开发人员或者不熟悉代码的业务人员也可以很快定位到代码位置。
微服务代码总目录¶基于 DDD 的代码模型包括 interfaces、application、domain 和 infrastructure 四个目录。
Interfaces（用户接口层）：