架构视角 - DDD、TDD、MDD领域驱动、测试驱动还是模型驱动?

提出问题

    「领域驱动设计」之于微服务,好比麦当劳之于汉堡(个人更喜欢肯德基,汉堡要大些,麦当劳的汉堡,想吃顿饱饭,请先给我上6个?)。但是TDD测试驱动、MDD模型驱动好像也很火啊,到底什么在驱动?

分析问题

不用着急,这是三个5分钟就能区分开的概念。开发中在协同工作。

首先纠正两个误区。DDD是Domain-Driven Design领域驱动设计。但是TDD和MDD的D意思是Development开发的意思。TDD对应测试驱动开发,MDD对应模型驱动开发。

这就是为什么很多大佬在大谈特谈「领域」,但是测试驱动、模型驱动其实也都在用,但谈的少些。因为这是我等实际一线写代码的同学才用的。

其次,它们三者之间的关系也不是感官直觉感受到的这种:

而实际上他们是在不同的阶段使用的方法。在我们团队,使用关系是这种:

下面会介绍我们团队怎么用的。

解决问题

在Eric Evans的《领域驱动设计-软件核心复杂性应对之道》中第一节的消化知识开始就开始建模。在我们平时的设计开发中,在描述总体设计思路也需要用模型也表示。一般常使用的图有:

流程图

 https://baike.baidu.com/item/%E6%B5%81%E7%A8%8B%E5%9B%BE

时序图 https://baike.baidu.com/item/%E6%97%B6%E5%BA%8F%E5%9B%BE/3659178?fr=aladdin

实体-联系图 https://baike.baidu.com/item/%E5%AE%9E%E4%BD%93%E5%85%B3%E7%B3%BB%E5%9B%BE/9005309

用例图 https://baike.baidu.com/item/%E7%94%A8%E4%BE%8B%E5%9B%BE/9531932?fr=aladdin

领域模型 https://baike.baidu.com/item/%E9%A2%86%E5%9F%9F%E6%A8%A1%E5%9E%8B/1022567?fr=aladdin

这些本质上是模型驱动开发的一种方法。现在很多公司和组织在研究一些更方便建模的工具。基于MDA(模型驱动架构)的工具涌现的比较多了,但是基本都是收费的。

在我们团队中,会用以文档形式,里面附加常用的图的形式来做初版方案的review。review完之后要进行可行性验证,这种会用代码建立一个demo版本。在这个阶段,需要将完整的测试用例都补充完整,并测试通过。确保测试用例的正确性。开发阶段,测试结果需要和建模阶段的结果一致。

所以可以理解为demo版是一个带有mock的粗糙开发版本。实际的开发阶段是对demo版本的重构。因为demo版实际功能已经实现了,测试用例不需要有改变。这也符合Martin Fowler的《重构-改善既有代码的设计》的思想。

总结

以提出问题为驱动,以解决问题为整合、用输出倒逼输入产品化。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券