关于TDD、BDD和DDD的一些见解

在实际的项目中，咱们可能随时面对各类不一样的需求，它的各个方面的要素决定了咱们所采用的开发模式。

好比，它的复杂度如何？全部的需求是否足够清晰？开发人员对相关的业务是否足够了解？项目的工期是否合理？种种问题，不一而足。这也决定了咱们可能面对不一样的需求可能须要采用不一样的开发模式。下面大概说几种。

 

1. TDD

TDD指的是Test Drive Development，很明显的意思是测试驱动开发，也就是说咱们能够从测试的角度来检验整个项目。大概的流程是先针对每一个功能点抽象出接口代码，而后 编写单元测试代码，接下来实现接口，运行单元测试代码，循环此过程，直到整个单元测试都经过。这一点和敏捷开发有相似之处。

TDD的好处天然不用多说，它能让你减小程序逻辑方面的错误，尽量的减小项目中的bug，开始接触编程的时候咱们大都有过这样的体验，可能你以为 完成得很完美，自我感受良好，可是实际测试或者应用的时候才发现里面可能存在一堆bug，或者存在设计问题，或者更严重的逻辑问题，而TDD正好能够帮助 咱们尽可能减小相似事件的发生。并且如今大行其道的一些模式对TDD的支持都很是不错，好比MVC和MVP等。

可是并非全部的项目都适合TDD这种模式的，我以为必须具有如下几个条件。

首先，项目的需求必须足够清晰，并且程序员对整个需求有足够的了解，若是这个条件不知足，那么执行的过程当中不免失控。固然，要达到这个目标也是须要作必定功课的，这要求咱们前期的需求分析以及HLD和LLD都要作得足够的细致和完善。

其次，取决于项目的复杂度和依赖性，对于一个业务模型及其复杂、内部模块之间的相互依赖性很是强的项目，采用TDD反而会得不尝失，这会致使程序员 在拆分接口和写测试代码的时候工做量很是大。另外，因为模块之间的依赖性太强，咱们在写测试代码的时候可能不采起一些桥接模式来实现，这样势必加大了程序 员的工做量。

 2. BDD

BDD指的是Behavior Drive Development，也就是行为驱动开发。这里的B并不是指的是Business，实际上BDD能够看做是对TDD的一种补充，固然你也能够把它看做 TDD的一个分支。由于在TDD中，咱们并不能彻底保证根据设计所编写的测试就是用户所指望的功能。BDD将这一部分简单和天然化，用天然语言来描述，让 开发、测试、BA以及客户都能在这个基础上达成一致。由于测试优先的概念并非每一个人都能接受的，可能有人以为系统太复杂而难以测试，有人认为不存在的东 西没法测试。因此，咱们在这里试图转换一种观念，那即是考虑它的行为，也就是说它应该如何运行，而后抽象出能达成共识的规范。若是你用过JBehave之 类的BDD框架，你将会更好的理解其中具体的流程。这里我推荐一篇具体阐述的文章。亲身体验行为驱动开发。

另外，关于TDD和BDD之间的关系，还能够参考这篇文章: 虚拟座谈会：代码测试比率、测试驱动开发及行为驱动开发

 3. DDD

DDD指的是Domain Drive Design，也就是领域驱动开发。这是一种很是好的思想，在咱们刚开始学习程序，甚至刚开始学习三层架构的时候，咱们曾经面临过不少疑惑，好比如何来实 现咱们的数据层？后来咱们开始学习MVC，MVP等架构，如何设计Model层又成了咱们的新问题。咱们见过太多这种状况，Model变成了单纯的数据容 器，也就是咱们常常说的贫血模式。DDD实际上也是创建在这个基础之上，由于它关注的是Service层的设计，着重于业务的实现，所以不可避免的以贫血 模式为基础而存在。可是它最大的特别是将分析和设计结合起来，再也不使他们处于分裂的状态，这对于咱们正确完整的实现客户的需求，以及创建一个具备业务伸缩 性的模型，是有很大帮助的。