学习资料来源:DDD独家秘籍视频合集 https://space.bilibili.com/24690212/channel/collectiondetail?sid=1940048&ctype=0
文章目录
- 动机
- DDD与重构
- 实践
- 重构? 重写
- 从一开始就采用DDD
- 重构步骤
- 1. 添加领域模块
- 2.分离出有价值的代码
- 3.迁移到领域模块
- 4.重复2,3
动机
- 为了程序员的理想? 为了商业利益?
- 通过重构老项目来学习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,分离出有价值的模块,直到你觉得没有有价值的模块需要移动。