学习资料来源：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，分离出有代价的模块，直到你以为没有有代价的模块必要移动。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
