为什么我要写这个系列

曾经在看完《测试驱动开发》后，我发现一大堆问题没解决，比如：如何最好地构建应用程序，让其易于测试，其实这也是最难的。因为我们绝大多数情况下，我们都因为不好测试而放弃。现在很多人流行所谓的DDD架构，也就是领域驱动编程。很多文章在说一些令人感到很牛逼的名词，譬如"六边形架构"， “端口与适配器”，“CQRS”，等等。但是我们必须承认，在未真正实践中做过这件事，我们可能真的无法理解到底是什么东西。幸运的是，我在网上看到了这么一个系列的文章，很好的解答了这个问题，他帮助我更好的思考代码的方法

TDD,DDD, 事件驱动架构

我们说烂了的管理复杂性的工具，以下排名不分先后

- 测试驱动

  测试驱动开发帮助我们构建正确的代码，让我们放心的重构和添加新特性，不用担心回归测试。但是我们很难从我们的测试中得到最好的结果：我们如何确保它们尽可能快的运行，怎么尽可能的减少测试的依赖？怎么进行端到端的测试都是让人头疼的问题，很多团队因为这个问题甚至放弃TDD开发

- DDD（领域驱动开发）

  领域驱动设计要求我们集中精力去建立一个良好的业务领域模型，但是我们如何确保我们的模型不会收到基础设施的问题阻碍而变得难以改变？

- 事件驱动架构

  通过消息集成的松耦合的微服务是管理跨多个应用程序和业务域复杂性成熟的解决方案。但是，如何让他们适应现有web开发框架，总不是那么明显，总感觉蹩脚。

## 怎么讲？

我会围绕一个实例程序，对以上模式进行探索，一章章地构建它，会按照一下两个部分进行讲解

1. 依赖倒置和领域建模

2. 事件驱动架构