一、TDD：测试驱动开发

测试驱动开发（Test-Driven Development, TDD）是敏捷开发中的一项核心实践和技术。针对每个功能点抽象出接口代码，然后编写单元测试代码。目前的一些模式对TDD的支持都非常不错，比如MVC和MVP等。

适合TDD这种模式的项目必须具备：

• 项目的需求必须足够清晰，而且程序员对整个需求有足够的了解。
• 项目的复杂度和依赖性要低。对于一个业务模型及其复杂、内部模块之间的相互依赖性非常强的项目，采用TDD反而会得不尝失，这会导致程序员在拆分接口和写测试代码的时候工作量非常大。另外，由于模块之间的依赖性太强，我们在写测试代码的时候可能不采取一些桥接模式来实现，这样势必加大了程序员的工作量。

二、BDD：行为驱动开发

行为驱动开发（Behavior Driven Development,BDD）。BDD旨在消除TDD过程中可能造成的问题。与TDD相比，BDD是通过编写行为和规范来驱动软件开发。 行为和规范可能看起来与测试非常相似，但是它们之间却有着微妙但重要的区别。

BDD更注重功能本身而非单纯的测试用例运行结果。BDD测试用例的描述采用了更加’繁琐’的风格，阅读BDD的测试用例就像是阅读一篇文档。这正是为什么我说BDD旨在消除TDD过程中可能造成的问题的原因所在。BDD赋予的这种像阅读句子一样阅读测试的能力有助于带来对测试认知上的转变，有助于我们去考虑如何更好写测试。当你可以流畅的阅读自己写的测试，你自然可以写出更好更全面的测试用例。

BDD是基于系统行为的一种测试方法，该方法基于系统行为定义出很多用于开发功能点的途径。Given(给予操作条件)-When(执行相关操作)-Then(得到预期结果)是用来编写测试用例的方法：

• Given（给予操作条件）：用户输入有效的登录凭证
• When（执行相关操作）：用户点击登录按钮
• Then（得到预期结果）：显示成功的验证消息

三、ATDD：验收测试驱动开发

验收测试驱动开发（Acceptance Test Driven Development，ATDD）技术，是从用户的角度编写了一个验收测试。 它主要侧重于满足系统的功能行为。 该技术用于检测代码是否按预期工作。

注意：ATDD与BDD非常相似，它们之间的主要区别是：BDD更多的是聚焦功能点的行为，而ATDD是捕获更精准的需求。

四、DDD：领域驱动开发

领域驱动开发（Domain Drive Design, DDD）是一种以业务为导向的软件设计方法和思路。我们在开发前，通常需要进行大量的业务知识梳理，而后到达软件设计的层面，最后才是开发。而在业务知识梳理的过程中，我们必然会形成某个领域知识，根据领域知识来一步步驱动软件设计，就是领域驱动设计的基本概念。而领域驱动设计的核心就在于建立正确的领域驱动模型。

对于现在流行的微服务架构，微服务的拆分一直都是微服务设计要解决的问题，而拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了。

解：DDD 核心思想就是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

注意：
对于简单的系统，如果后续业务不会有太大变化，那么就不适合用DDD。

五、持续集成CI

持续集成（Continuous Integration, CI），是指频繁地（一天多次）将代码集成到主干，然后放到CI Server上自动化跑一遍，如果代码有问题就会原路打回来，这样做的目的就是为了能够尽早发现错误，从而能即时在最短的时间内定位你的错误并且改正。

六、持续交付CD

持续交付（Continuous Delivery, CD）是在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」中，是一个更小粒度提交的过程。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中Jj进行测试。如果代码没有问题，可以继续手动部署到生产环境中。

七、持续部署CO

持续部署（continuous deployment，CO）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。

在持续交付后生成可执行的制品，需要尽快验证是否存在功能性能等方面的问题，或者尽可能快速的让最终用户可以使用这些功能。通过持续部署到测试环境、准生成环境中，可以使测试团队尽快开始测试，开发团队获得快速的反馈并响应。使研发和测试的协同加快了进程。通过持续部署到生产环境，让最终用户可见，则可以快速获得最终用户的使用反馈，体现需求的市场价值。

八、DevOps

DevOps （Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

分布式架构+敏捷开发模式

微服务架构+DEVOPS