架构视角 - 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的《重构-改善既有代码的设计》的思想。

 

总结

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

 

推荐阅读

程序经常使用的设计技巧

到底多大才算高并发？

美团分布式服务通讯框架及服务治理系统OCTO

学会用数听说话-分布式锁究竟能够多少并发？

大话高可用