高并发架构实战 Day25

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