学习资料来源：DDD独家秘籍视频合集 https://space.bilibili.com/24690212/channel/collectiondetail?sid=1940048&ctype=0

动机

• 为了程序员的理想? 为了商业利益?
• 通过重构老项目来学习DDD并不合适。DDD应该是项目一开始就使用DDD，而不是用它来做重构。
• 考虑投入产出，收益不高不做。死代码，没有新的需求来了，没必要重构；或者去先做其他更收益更高的事情
• 得到各方支持，测试、产品、领导。不要私自做，难以坚持下去。

如果你是打工的，代码是公司的，不是你自己的。哪怕是座屎山，也不要轻易重构或DDD改造，屎山也能带来商业价值。改造能对屎山代码起到很好效果的几乎没有。

DDD与重构

• DDD和重构不存在直接关系。DDD不是指导重构的方法论，重构也不需要DDD的指导。一个完全不懂DDD的人，也可做重构。
• 实践DDD最好不要从重构开始。DDD最核心的部分是从问题域出发，设计出领域模型，再将模型落地为代码。但是重构不是从问题域出发的，而是从老代码出发的。
• DDD架构风格可以成为重构的目标。
• 如果老项目本来就是用DDD做的，可以通过重构不断改进DDD代码。

实践

重构? 重写

首先要搞明白，是要做重构还是重写。
重构是不改变功能，逐步改进代码，量变引起质变。增量改变，风险更小。
重写是抛弃老代码，完全写一份新的，往往是一次性完成的。重写风险更大，一般不建议采用。
不管是重构还是重写，都应该用测试驱动开发保驾护航。如果原有代码确少测试用例，首先要补充自动化的测试用例。单元测试、集成测试、接口测试等等。然后再重构，如果只靠人力，很可能会失败。

从一开始就采用DDD

如果是新项目或者新需求，目前这个年代，使用DDD成本并不高。如果一开始不是DDD，后期重构成本更高。

重构步骤

1. 添加领域模块

这里的领域模块，就是业务核心模块，六边形架构里边所说的核心。刚建出来这个模块可能是空的，具体表现如在Java项目中可能是个jar包。

2.分离出有价值的代码

不可能一下子把老代码都用DDD改造。把最有价值的模块分离，并定义接口，老代码使用接口，待分离模块实现接口。接口把功能的使用方和实现方隔离开来，接口到后边不再变化，代表了老代码和分离模块之间的协议。

3.迁移到领域模块

4.重复2,3

重复步骤2,3，分离出有价值的模块，直到你觉得没有有价值的模块需要移动。