什么是MDD，DDD，TDD?

最新推荐文章于 2024-10-08 22:09:56 发布

adventure.Li

最新推荐文章于 2024-10-08 22:09:56 发布

阅读量4.9k

点赞数 1

分类专栏：软件架构&设计方案文章标签： tdd 驱动开发

本文链接：https://blog.csdn.net/qq_44654974/article/details/127714951

版权

软件架构&设计方案专栏收录该内容

13 篇文章 1 订阅

订阅专栏

前沿

随着软件行业的飞速发展，从软件的管理、开发、测试运维等各个角度、环节都很着许多针对新业务场景产生的新技术。而在对于MDD,DDD,TDD这几个长得相似的几个名词相信也是十分常见的，以下做个总结。

一、关于MDD

简述

MDD（模型驱动开发）代表了一套理论和工业化软件开发的方法框架，在软件开发全生命周期中系统的使用模型作为主要工具。是一种以模型作为主要工件的高级别抽象的开发方法，是iuap平台下的元数据驱动设计框架，前后端的统一基于元数据的框架。

背景

只看概念，是十分抽象难以理解的。我们需要去结合MDD的目标回顾以下软件的大致发展过程。
首先MDD的核心思想：

分离领域业务与技术平台的耦合
极大提升业务领域模型和技术模型在软件生命周期的复用

PIM（与平台、技术无关的模型） → PSM（技术平台具体实现的模型）

任何技术都来源于业务问题\用户的需求。随着软件的繁荣，高级语言的众多，在软件由现实世界映射为虚拟世界的过程中，不同语言采用的抽象层有所差异，因此需要寻求一种更为通用性的方案解决。概括来说当时/现在的软件危机/背景为：

复杂性
变更性

而软件的关注的角度主要为：业务领域 + 技术平台 + 问题抽象；我们在开发软件的过程则是将业务领域进行问题抽象，并采用技术去映射为机器代码的过程。作为软件开发工程师，为了更好地去解决复杂、易变的业务问题，出现了高级编程语言以及复用的思想，因此构建软件更加便捷。其中的复用理解十分关键，也需要从软件的发展去看待复用什么以及如何复用。软件的发展大致可以为以下阶段：

以机器为中心：通过0\1指令去控制机器，人们需要记忆机器指令，利用机器的思维去处理，此时基本上是软硬件一体化时代，此时还未体现复用，一般处理科学计算。
汇编时代，辅助符号去代替机器指令，但任然需要记忆寄存器、PC等指令，计算机内部世界，不过开始向人的思维过度。
高级语言及OS的出现，此时出现了巨大的改变，此刻人们则面向操作系统进行编程，中间有了操作系统的中间层，我们无需关注底层实现，甚至内存管理也无需关心。我们只需要关心高级语言的特性，如何利用高级语言去处理业务问题。但高级语言之间有着差异。因此，不同高级语言之间难以复用。解决该问题的方式可以为：

建模，则可用该处的MDD，模型驱动开发，先进行建立通用模型，然后对于不同的高级语言都可以利用该通用的模型去开发。相对于在 OS 和高级语言之间建立了一层抽象层。常见的建模工具则是UML了，也是业界常使用的。
中间件（也是第四点，以企业为中心），不同语言只需去调用不同中间件提供的服务即可。

而 RPC 远程调用，解决的则是不同（不同语言）程序之间可以进行通信，可以并行开发，业务服务组件之间可以替换，也类似有点复用的意味，但没有明显的建立中介抽象层。
微服务追求业务层面的复用，服务的粒度更小，更便于替换。

更进一步，现在的serverless，直接面向用户提供计算、存储服务。

基本过程

关于模型的定义抽象过程如下图：
在这里插入图片描述

具体的讲解可参考参考博文

简单应用

对于UML的使用工具常用的UML设计工具有微软Office自带的Visio、Rational Rose、PowerDesign以及StarUML、EA（Enterprise Architect）。对于UML大家肯定都听说过了，毕设或者课设一般都会用来画类图、交互图等。
但对于Eclipse的EMF建模工具，可能还没使用过，该建模工具则基于的ECore构建标准进行实现。具体的使用可参考：百度知道

二、关于DDD

有了MDD的基本概念，来理解DDD更好理解了。

基本概念

DDD（Domain-driven design）领域驱动设计是一种通过将实现连接到持续进化的模型来满足复杂需求的软件开发方法。领域模型是对业务模型的抽象，DDD是把业务模型翻译成系统架构设计的一种方式。

由概念可知，DDD则是重点关注在业务的层面，而MDD则是整个环节或者侧重于业务到技术的中间层。

在这里插入图片描述
关于DDD的更多介绍可以参考
博文1
博文2
对于DDD的项目示例，比较推荐周志明老师的《凤凰架构》中的示例项目。以及阿里巴巴微服务脚手架COLA（面向对象架构），官方GitHub；脚手架地址

对于DDD 和 COLA 的区别，请见该文

在这里插入图片描述

三、关于TDD

概述

TDD是测试驱动开发（Test-Driven Development）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。

相对于前面两个概念，TDD更为简单，即测试先行。有面向失败设计的思想。为了保证开发的准确，先将进行编写测试（单元测试），在此过程中更利于去加深对业务的理解，降低错误。

基本原则

独立测试：不同代码的测试应该相互独立，一个类对应一个测试类，一个函数对应一个测试函数。用例也应各自独立，每个用例不能使用其他用例的结果数据，结果也不能依赖于用例执行顺序。一个角色：开发过程包含多种工作，如：编写测试代码、编写产品代码、代码重构等。做不同的工作时，应专注于当前的角色，不要过多考虑其他方面的细节。
测试列表：代码的功能点可能很多，并且需求可能是陆续出现的，任何阶段想添加功能时，应把相关功能点加到测试列表中，然后才能继续手头工作，避免疏漏。
测试驱动：即利用测试来驱动开发，是TDD的核心。要实现某个功能，要编写某个类或某个函数，应首先编写测试代码，明确这个类、这个函数如何使用，如何测试，然后在对其进行设计、编码。
先写断言：编写测试代码时，应该首先编写判断代码功能的断言语句，然后编写必要的辅助语句。
可测试性：产品代码设计、开发时的应尽可能提高可测试性。每个代码单元的功能应该比较单纯，“各家自扫门前雪”，每个类、每个函数应该只做它该做的事，不要弄成大杂烩。尤其是增加新功能时，不要为了图一时之便，随便在原有代码中添加功能，对于C++编程，应多考虑使用子类、继承、重载等OO方法。
及时重构：对结构不合理，重复等“味道”不好的代码，在测试通过后，应及时进行重构。
小步前进：软件开发是复杂性非常高的工作，小步前进是降低复杂性的好办法。

四、一些小思考

软件的发展是朝着人的思维发展，而人的思维行为具有很多不确定性，人与人之间也用着复杂的关系。正是因为这些不确定性和复杂关系导致软件的复杂。而解决软件的复杂的最好办法则是不断寻求好的中间层进行抽象，并进行有效地抽象问题和复用，避免重复劳动。

另外，软件关注的主要有 质量 + 效益 + 成本。我们在关注效率的同时也要注意成本，当然效率的提升基本是会给成本的带来降低。现在越来越多的中小企业之所以愿意选择serverless服务，很大程度是因为，云原生提供了极好的服务，在不是高数据安全的要求之下，企业愿意去负担该笔费用，避免硬件的购买的昂贵费用。