学习视频来源:DDD独家秘籍视频合集 https://space.bilibili.com/24690212/channel/collectiondetail?sid=1940048&ctype=0
文章目录
- DDD与敏捷开发的关系
- 敏捷宣言
- DDD与敏捷开发相互助力
- 1. 都强调人与人的协作
- 2. 都强调迭代
DDD与敏捷开发的关系
DDD与敏捷开发不存在必然关系。DDD要解决的问题是如何设计软件,是软件设计的一个方法论。敏捷开发是解决如何多人协作开发软件,是工程方法论。敏捷开发主要解决如果在有限的时间、人力、资源下,把事情做好的问题。用敏捷开发可以使用DDD,也可以不使用DDD,使用DDD可以不使用敏捷开发,当然使用了敏捷开发更好。它们之间不存在必然关系。
敏捷宣言
敏捷宣言(http://agilemanifesto.org/)相对于传统的、比它更早出现的瀑布式开发,更关注的是人和人之间的互动、交流的价值。而不是把纸面的文档、规定的流程、计划等当作最重要的东西,这是它很关键的一个部分。另一个方面,敏捷开发强调可工作的软件重于面面俱到的文档,让这个软件能解决问题是最重要的,所以敏捷开发一般都是采用迭代的方式,一步一步的把软件做出来,而不是一开始就把所有的东西都想好,然后再一下全部设计出来。
DDD与敏捷开发相互助力
1. 都强调人与人的协作
- DDD的通用语言、领域模型、事件风暴等可以帮助沟通
通用语言就是大家要把术语统一掉,在某一个上下文里边,要用什么样的词汇去描述一个概念,这个需要到一个人与人协作的具体场景里边去。领域模型和事件风暴也是一样的,都需要人与人协作、沟通、分析。 - DDD的领域模型、六边形架构、CQRS等可以帮助评估工作量
对于一个新的需求,可能是一个新的项目,也可能是对历史需求的一个迭代。如何在短时间内让大家都能理解这个需求需要对哪些东西做变更,是一个困难的事情。
在不使用DDD的情况下,往往都是以面向数据库的方式来说。如果我的数据库表要做哪些变更,我的接口要做哪些变化等等。这样的方式往往很难把这些问题说清楚,比如产品等并不关心了解这些,或者不是负责这块的程序员也不了解这些细节,需要去看代码,才能知道要发生哪些变更,评估出具体的工作量。
在使用DDD的情况下,需要变更的东西我们可以通过领域模型来表达出来,这样就把新需求就转换成了需要对领域模型做哪些变更。比如新加了什么聚合、已有聚合有什么变更、多了什么样的命令、领域事件等等。这样对于知道这个领域模型人来说,就知道哪些东西发生了变更,代码如何去写,可以很好的去做分工。每一块的工作量也可以更好的去评估,因为大家都清楚难点在哪里,评估工作量会更加的透明化。但如果使用面向数据库的方式,往往很难把这些问题说清楚。
2. 都强调迭代
- DDD有柔性设计、精炼领域模型
在做领域驱动设计的时候,不必一次就设计出完美的领域模型。刚开始只要能设计出一个可用的领域模型就行,而且也不存在一个完美的领域模型。当新的需求来时候,对于那些经常需要发生变化的领域,我们再进行更多、更细致的设计,这些部分需要更良好的易读性和扩展性,需要精炼。对于那些不怎么发生变化的领域,是不值得去优化的,因为也没有人会关注这些部分,所以我们不需要去精炼,只要它能带来价值,没有问题就行了。 - DDD的领域模型让测试更容易,迭代过程中的重构更容易
迭代就意味着变更,变更就意味着要对代码进行修改。一旦代码发生变更就可能会引发线上故障,这个时候就需要测试、回归,所以测试非常重要。有很多问题不是通过你学了多少东西来解决,而是通过测试来解决,只要掌握了测试方法论,你就把问题解决掉了。
领域模型不依赖具体技术实现,容易被测试。DDD不依赖于具体的技术实现。不依赖于数据库、消息中间件、文件读写、底层框架等具体实现。它的代码基本就是简单的POJO,这样的代码是非常容易被单元测试,因为它容易被mock。假如你的代码里既包含业务逻辑,又包含与这些技术实现直接耦合的逻辑,那你对这样代码进行测试,是比较困难的。PS:个人实际情况中,不用DDD其实也不直接依赖于这些技术的技术实现。
所有业务逻辑都被包含在领域模型中,测试领域模型即可以测试所有业务逻辑。
我们在设计领域模型的时候,要杜绝将业务逻辑泄露出去。除了业务逻辑之外的逻辑/模块,比如HTTP框架、Tomcat、数据库等,这些中间件已经经过了开发者充分测试,我们不需要再进行这些功能测试,我们只需要关注自己写的业务逻辑即可。而我们自己写的业务逻辑都包含在领域模型中,所以我们只需要对领域模型里的逻辑进行充分测试即可。