提出问题
「领域驱动设计」之于微服务，好比麦当劳之于汉堡(个人更喜欢肯德基，汉堡要大些，麦当劳的汉堡，想吃顿饱饭，请先给我上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?
实体-联系图
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的《重构-改善既有代码的设计》的思想。
总结
以提出问题为驱动，以解决问题为整合、用输出倒逼输入产品化。
