使用 DDD 进行系统重构的过程分为以下六步:
讨论当前系统存在的问题,发现问题背后的根源。比如:架构与代码混乱,需求迭代困难,部署麻烦,bug 率逐渐升高;微服务边界不清晰,调用依赖关系复杂,团队职责混乱。
针对问题分析具体原因。比如:微服务 A 太庞大,微服务 B 和 C 职责不清,团队内业务理解不一致,内部代码设计不良,硬编码和耦合太多。
重新梳理业务流程,明确业务术语,进行 DDD 战略设计,具体又可以分为三步。
a. 进行头脑风暴,分析业务现状和期望,构建领域语言;
b. 画泳道活动图、结合团队特性设计限界上下文;
c. 根据架构方案和非功能需求确定微服务设计。
针对当前系统实现和 DDD 设计不匹配的地方,设计微服务重构方案。比如:哪些微服务需要重新开发,哪些微服务的功能需要从 A 调整到 B,哪些微服务需要分拆。
DDD 技术验证。针对比较重要、问题比较多的微服务进行重构打样,设计聚合根、实体、值对象,重构关键代码,验证设计是否合理以及团队能否驾驭 DDD。
任务分解与持续重构。在尽量不影响业务迭代的前提下,按照重构方案,将重构开发和业务迭代有机融合。