关于领域驱动设计的一些思考

领域驱动设计(DDD, Domain-Driven Design)是一套综合软件系统分析和设计的面向对象建模方法。在DDD提出之前，系统分析和系统设计都是分离的，这样割裂的结果导致需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。

一、领域驱动设计的好处

DDD最大的好处是接触到需求第一步就是考虑领域模型，而领域模型的价值在于提供一种通用的语言，使得领域专家、产品经理和软件技术人员联系在一起，沟通无歧义。DDD的革命性在于领域模型准确反映了业务语言，它让你首先考虑的是业务语言，而不是技术语言。

二、领域驱动设计对现实工作的价值

从实际工作出发，个人认为领域驱动设计（DDD）的主要价值有二。

第一，DDD有助于弥补技术人员与业务人员的认知鸿沟。在实际工作中，业务人员只关心业务流程，技术人员只关心技术实现本身，两者之间的理解和认知差异，导致经常出现“鸡同鸭讲“的现象。而领域模型本身则无关技术，具有高度的业务抽象性，它能够精确地描述领域中的知识体系。借助于领域模型作为媒介，可以有效弥补两者之间的认知差异，使得软件更贴近于业务实际。

第二，DDD对微服务的架构设计具有重要指导意义。基于领域驱动的架构设计提倡先设计领域模型作为逻辑边界，再根据逻辑边界划分具体的物理边界（物理边界即具体的微服务划分）。借助于较为清晰的边界，可以实现微服务生态系统分而治之的基本设计思路，以及面对需求快速变化、面对流量爆发式增长时的快速迭代和快速扩展扩容，才可以获得更好的迭代速度和更高的系统性能。

从实际工作出发，我们的不少老系统（比如基于c、基于cobol的系统）采用的是面向过程的设计方式，在向Java等面向对象语言、向微服务分布式架构迁移的过程中，不能将其单单理解为编码语言的转变，更重要的是一种整体性、革命性的设计思路的变化。在这个迁移过程中，基于领域驱动的设计思维非常重要。

如果不是基于领域驱动的思路进行微服务架构设计，而是单纯理解为基于业务功能/流程的简单拆分（典型如烟囱式的微服务设计），那么微服务之间将具有异常强大的相互关联性，微服务生态系统整体则体现为典型的“低内聚，高耦合”，将给开发联调、功能测试、版本部署、线上问题追踪排查以及后期维护带来严重的后果。

从设计思路上讲，基于领域驱动的架构设计本质上是面向对象设计思维的一个具体应用；而基于业务功能/流程的简单拆分，则是传统的面向过程设计的延续。

从组件可重用的角度讲，基于领域驱动架构设计的组件明显具有更强的通用性，只要组件涉及的领域相同，便基本可以考虑重用；而基于业务功能/流程设计简单拆分的组件，本质上只是为整个机器专门定制的一颗螺丝钉，用途是特定的，基本不具有可重用性。

三、总结

领域驱动设计（DDD）对于实现业务技术融合、弥补业务人员和技术人员之间的认知差异，对于指导微服务架构的设计，具有很高的指导作用，强烈推荐。