戏说领域驱动设计（一）——开场

　　为什么叫“戏说”呢？领域驱动设计出来的时候就有一种对于受众的调戏。书是读完了，您个人升华到了“看山非山，看水非水”的境界。再看一下落地代码，搞不好会仰天长啸：“这是我写的？”。佛家讲“空”，儒家讲“仁”，领域驱动讲“真”。真者，本质也。当您到了“真”的境界，就不会再与别人争论“到底是java还是C#好”，也不会再纠结“我这个设计合不合理啊？”。很多东西自然而然的就出来了。

　　回顾历史，领域驱动设计（Domain-Driven Design，简称DDD）大概源起于2004年。有个洋人叫Eric Evans出了本书叫《Domain-Driven Design : Tackling Complexity in the Heart of Software》（领域驱动设计：软件核心复杂性应对之道）（其实我更关心副标题）。全书大概包含两部分：战略设计、战术设计。战略方面关注如何将大系统划小；战术方面关注划小后的软件如何设计。随着时间的推移，陆续有一些大家对领域驱动中的战术部分进行了补充，比如“命令查询分离架构（CQRS）”、“事件溯源（ES）”等。

　　从2004年至今16年+的时间里，按理DDD这套东西早就应该过时了，尤其在是IT圈中。十多年间IT技术变化飞快，很多人连Java8还整不明白，人家已经推出了Java17。但当我们翻看网络上面DDD相关的文章与书籍的时候，发现这套思想与战术相当活跃，被一些互联网大厂，保险公司和金融公司广泛使用。这个时代的技术人员是幸运的，2010年前的DDD学习者所经历的那段知识蛮荒何其悲哀。

　　纵观网络上对DDD的评价，有嘲讽的、有鼓吹的、有茫然的，你能在他们的脸上发现世间百态。不过总结起来，大家一致的想法是：“真难”。其实也很正常，Evic Evans、Martin Fowler这帮人可是这个圈子的绝世高手，常年混迹在国外各类面向对象圈子。当您还觉得练武的最高境界是手中无剑心中有剑的时候，那帮祖师爷已经还始自创神功了。况且，早在DDD之前已经有一帮先驱设计出了各类分析与设计方法，与其说老艾创造了DDD，不如说其是对前人及个人经验的总结与梳理。此外，DDD、微服务这些理论的最初都是英文所写。圈外老外看着都蛋疼，何况非英文母语国家的人 ？

　　DDD中的战略部分中，一开始就讲到了子域与限界上下文，给了读者一计重击。我说DDD是超前的，为什么呢？让我们的脚步回退到2010年之前，那是个没有k8s、Docker、Spring Cloud的时代。假如我们严格按书的理论，把一个大型的系统分离成了很多很多的小系统，比如100个。即便有个一流高手，对系统做了合理的拆分，谁敢去高落地？100个服务，即使是双实例服务数量也高达200，怎么部署？服务间的调用链路如何跟踪？服务如何管理？所以说，“看不懂，不理解”很正常。那东西本来也只能有选择的落地。2010年后各类云原生技术有了高速发展，此时才是DDD大展伸手的最好时机。

　　再来谈一下微服务与DDD的关系。微服务是一套思想也是一种架构风格，Martin Fowler大概于2004年提出。现在其所以可以大行其道，是因为有一套完整的云原生技术做支撑。部署有容器，流程有DevOps和各类工具，开发技术有Spring Cloud。可是一套系统想要使用微服务架构，最起码得先把微服务拆出来，这个就是DDD要干得事情了。它有一套理论告诉你如何将系统划小，还有一套技术告诉你如何针对每一个划小后的系统进行设计。所以，两者之间是一对儿老铁。着重提一句，如果您的公司组织结构不适合微服务架构（比如部门10个人，8个当领导的；比如开发同时也是运维），整个单体或有限个小单体没毛病，DDD不一定要使用微服务架构。一流高手即使最初是以单体方式落地一个系统，也可以在后续实现系统的快速拆分，这叫“专业”。

　　学习DDD之前，推荐几本老书看看。书多且厚，您怎么也得每天认真的看1个小时吧？花花世界诱惑忒大，努力让自己做沉浸式阅读。

• Head First 设计模式：学习一些基础的面向对象概念和重要的设计模式，为实际落地作准备
• UML和模式应用：学习如何建模
• 企业应用架构模式：拓宽一下眼界
• 实现领域驱动设计：很厚重的一本，相对老艾的更加务实，推荐重复阅读
• 领域驱动设计：软件核心复杂性应对之道，DDD开山之作，挺玄幻的

开场讲完，DDD对人的要求贼高，怎样才能在DDD的路上走得更远，且听下回分解。最后，一句“天行健，君子以自强不息”与读者共勉。