构建领域驱动设计知识体系
本次演讲是我创作GitChat课程「领域驱动战略设计实践」和「领域驱动战术设计实践」这两年来，随着对领域驱动设计的深度理解，结合自身项目经验总结的领域驱动设计知识体系。
本次演讲内容分为四个部分：
领域驱动设计的历史回顾
对领域驱动设计的新定位
领域驱动设计参考过程模型
领域驱动设计能力评估模型
从2004年Eric Evans的经典著作《领域驱动设计》出版开始，在这十五年间，我个人认为有四个重要的里程碑值得重视。
里程碑之一：领域驱动设计的诞生
里程碑之二：领域事件的引入
它的重要意义在于拓宽了领域驱动设计的建模范式，引入了以“事件”和“函数”为核心的新的领域驱动设计模式，如Event Store、Event Sourcing、Pure Function等：
架构模式也发生了变化：
里程碑之三：微服务的引入
毫无疑问，微服务概念以及该架构模式的产生与发展，对领域驱动设计产生了深远的影响。它的引入对企业应用系统的设计与开发带来了各方面的影响。
首先是设计理念的改变。传统的数据模型驱动设计并不适合微服务架构。例如，那种以数据库SQL或存储过程操作数据的方式，在微服务架构下已经不具备优势：
其次，领域驱动设计引入的限界上下文边界与聚合边界更适合微服务架构：
通过防腐层（ACL）与开放主机服务（OHS）维护好限界上下文的边界，有利于单体架构向微服务架构的迁移：
领域驱动设计强调领域模型与数据模型的分离，在从单库单表的数据结构迁移到多库多表时，领域模型受到的影响较小，同样有利于单体架构到微服务架构的迁移。
在2017年的DDD中国峰会，我对肖然笑称是“微服务拯救了领域驱动设计”，但这个说法其实比较过分，因为领域驱动设计并没有岌岌可危，只是并未成为国内软件开发的主流而已，因而我改为一个更加温柔的说法：微服务让领域驱动设计焕发了青春。
但是，到了2019年的今天，我却要改变这一说法：不是微服务让领域驱动设计焕发青春，而是微服务“爱上了”领域驱动设计，二者其实是天作之合。
里程碑之四：中台战略的引入
ThoughtWorks的王健将微服务定义为：企业级能力复用平台。我很认同这一定义，如果仔细分析这九个字的定义，也可以从领域驱动设计中找到映射。
首先，领域驱动设计中问题空间的子领域和解决方案空间的限界上下文就体现了企业级能力：
其次，领域驱动设计强调将领域层独立出来，即可形成对领域模型的复用：
领域驱动设计的四重边界与整洁架构思想的遵循，可以帮助我们更好地完成平台的沉淀：
中台战略（Zhongtai Strategy）是否能够更好地与领域驱动设计结合，或许答案还未可知，但我们可以对其进行探索。
我认为领域驱动设计从最初的一种技术体系，到现在已经发展成了一种设计哲学：
为此，我建立了领域驱动设计魔方，分别从X、Y、Z三个维度对领域驱动设计进行了梳理：
我基于Y轴划分的宏观层次、微观层次与纳米层次分别介绍了领域驱动设计魔方：
在领域驱动设计魔方中，我引入了业务架构、系统上下文、事件风暴、整洁架构、RAID风暴、RUP 4+1视图、康威定律、精益需求管理、敏捷过程管理、场景驱动设计、测试驱动开发和测试战略。这些内容在PPT中都有介绍，这里就不再赘述。
固化领域驱动设计的过程，提供简单有效的实践方法，建立具有目的性和可操作性的研发过程。
在全局分析阶段，参考过程模型的实践包括：
在战略设计阶段，参考过程模型的实践包括：
如果当前限界上下文属于核心子领域，则应该为该限界上下文开展领域模型驱动设计，这一阶段的参考过程模型包括：
借助领域驱动设计魔方与领域驱动设计参考过程模型引入的各种方法与模式，我建立了一套领域驱动设计能力评估模型。
领域驱动设计能力评估模型（Domain-driven design Capability Assesment Model， DCAM）是我个人对领域驱动设计经验的一个提炼，可以通过它指导团队进行能力的培养和提升。
DCAM并非一个标准或一套认证体系，更非事先制定和强制执行的评估框架。建立这套模型的目的仅仅是为了更好地实施领域驱动设计，它是一个能够不断演化的评估框架。
该能力评估模型针对的能力维度包括：
敏捷迭代能力
领域建模能力
架构设计能力
整洁编码能力
敏捷迭代能力
领域建模能力
架构设计能力
整洁代码能力
领域驱动设计的落地取决于一个成熟的领域驱动设计团队。利用DCAM对团队进行评估，在发现团队成员的能力短板后进行针对性的培训，一旦提升了整个团队的成熟度，在领域驱动设计的精髓指导下，距离领域驱动设计的成功就不远了！
感谢我的老东家ThoughtWorks以及DDD中国峰会给我这样一个机会进行一次主题演讲，也感谢GitChat“逼迫”我不断创作，完成了近100章数十万字的《领域驱动设计实践》课程的写作。