DDD是一套围绕领域建模进行软件开发的模式，一共有四十多个。这些模式成为《领域驱动设计》这本书的主体。如果以平常心来对待DDD，把它当成一套模式的集合，发现哪个模式对我们有用就拿来用一下，不能用也不要勉强(DDD的限界上下文、聚合、实体、值对象等等，都可以认为是一种模式)，以这种拿来主义的心态去使用DDD，反而可能会渐入佳境，也不会造成太大负担。

事件风暴

事件风暴是一种通过协作的方式捕获行为需求的方法，在这个过程里，业务人员和技术人员一起消化领域知识、形成统一语言、并为领域建模奠定基础。事件风暴分为识别领域事件、识别命令、识别领域名词三个步骤。这一节课讲的是后面两个步骤。“命令”是引发领域事件的操作，可以从领域事件“反推”出来。此外，还可以识别命令的两个附加信息，一个是发出命令的“执行者”，另一个是为了完成命令要查询出的数据。“领域名词”是隐含在命令和领域事件中的名词性概念。这些名词是领域建模的素材, 而对于这些素材的深入分析可以留到领域建模进行。

模型驱动设计

模型驱动设计可以分成两大部分：模型的建立和模型的实现。模型的建立要求模型和业务需求一致，模型的实现要求实现和模型一致。

分层架构

分层架构把代码分成若干层，每层负责不同的关注点。图里的箭头表示依赖关系，这里的意思是只能外层依赖内层，内层不能依赖外层。这背后其实是根据软件架构中的一个重要原则：代码中不稳定的部分，应该依赖稳定的部分。所以，分层架构中越是内层，就越稳定，越是外层，相对就越容易变化。

仓库Repository和前面的 Controller 虽然都是适配器，但有一个重要的区别。Controller 处理的是从外界向系统的调用，比如说来自 HTTP 客户端的调用；而仓库处理的是由系统向外界的调用，比如说对数据库的调用。也就是说，两者的方向不同。在六边形架构里，把由外向内的适配器叫做 driving adapter，我把它译作主动适配器；而由内向外的适配器叫做 driven adapter，可以译作被动适配器。准确地说，被动适配器的作用不限于访问数据库，而是访问所有外部资源。