DDD为什么很难实施

领域驱动设计（Domain Driven Design）的概念已经被发明了十多年，而且也不乏相关著作，但是业界宣称自己应用了DDD原则的项目，软件却鲜有耳闻。随着微服务架构的流行，DDD在边界识别，服务划分等方面不断被提及，作为一种应对复杂软件的方法论，似乎又被重视起来了。

那么，为什么这个听起来很靠谱的方法论实际上很难实施呢？我们以DDD创始人Eric Evans的经典书籍《领域驱动设计：软件核心复杂性应对之道》为例，分析一下，可能的原因是这样的：

新概念数量比较多

战术/战略都有所涉及

不同层次的概念混杂（除了设计模式之外，还有架构风格的讨论）在一起

繁复而混杂的概念

领域，子域，核心子域，通用子域，实体，值对象，领域服务，应用服务，领域事件，统一语言，衔接上下文，遵循者等等。DDD中有着大量的新概念，而且这些概念有些是技术相关的，有些是问题相关的，交织在一起之后，很难理清头绪。

DDD中的模式又分为战术的和战略的两大部分，有很多团队应用了战术相关的，比如实体，值对象，领域服务，仓库等模式，代码看似DDD，实则与DDD强调的以领域为中心相去甚远，陷入了开发者太过于关注技术本身的老路上，这种现象还有个专门的名词，叫DDD-Lite。

不同的思维方式要求

DDD要求读者既有具体Coding的技能，有需要跳出圈外，以架构师的角度来审视整个系统。DDD需要开发者以一个全新的视角去认识软件开发，强调对业务流程的熟悉，强调与领域专家一起协作，强调软件的表达能力和进化能力。而这些思维方式的转变，都有很大阻力的（想想从面向对象世界切换到函数式编程，再到响应式函数编程的切换）。

It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter. – Nathaniel Borenstein

我自己在工作的前4年，非常反感业务，认为case by case的业务流程会严重影响我的代码的通用性。然而事实是，纯粹通用的代码是不存在的。毕竟，诸如IoC容器，Web等基础设施已经相当完善，完全无需我们重复发明轮子。而作为应用开发人员，更重要的是在充分理解业务的前提下，写出易于维护，易于扩展，可以更快速响应业务变化的代码。

正因为如此，DDD在一定程度上会让程序员感到不适，它太强调领域了，而领域又是独一无二的，每个公司的每个系统都有其独立性，这就要求你的代码可能没法做到纯粹。

正确姿势

要解决上面提到的这些问题，正确的实施DDD来指导实际的开发工作，需要至少做到这样几个事情。首先，明确分清问题和方案（这是初学DDD者最容易犯的错误）；其次，转变思维方式，将软件开发的重心放在梳理并明确业务需求上，而不是代码逻辑上；最后，需要应用一些合理的工程实践来促成DDD-Lite的落地。

分清问题和解决方案

我们说领域（子域，通用子域，支撑子域等）的时候，是在讨论问题域，即定义我们要解决的问题是什么。而说到限界上下文，聚合，实体，仓库则是在讨论解决方案部分，人们很容易将两者搞混。

在电商的领域中，一些典型的问题是：

如何获得更多的客户

如何让客户更快速的找到自己想要的商品

如何准确的推荐相关产品给客户

用户如何付费

要解决这些问题，人们可能会开发出来一个软件系统，也可能会用手工的流程，也可能是混合模式。同样，一些具体的解决方案的例子是：

商品促销子系统

全文搜索系统

推荐子系统

支付平台

显然，解决方案是在问题定义之后才产生的，而定义问题本身是一件开发人员不擅长的工作，这也是为什么DDD特别强调领域专家的原因。实施DDD需要从领域专家，技术专家的深入合作中，得出一个模型。其实，DDD的核心就是要解决一个问题：建立领域问题的软件模型，这个模型需要满足这样几个条件：

能准确表达领域概念，业务流程等（无需经过翻译）

容易演进

每个领域有自己的解决方案

DDD战略模式

这是Vaughn Vernon的著作《Implement Domain Driven Design》中的一张图，整个外边的大圈是业务对应的领域（问题域），这个大的圈被虚线划分成了很多小的子域（依然是问题域，不过每个子域要解决的问题都不相同），子域有很多类型，比如核心子域，支撑子域，通用子域等。对应的，每个域都可能有自己的限界上下文，上下文之间有不同类型的上下文映射模式。

子域的边界由通用语言来划分，也就是说，每个子域有自己区别于其他子域的语言（也就是自己的业务概念，业务规则）。比如财务系统中，提及的概念如毛利，净利率，投入回报比，发票，报销等等，与招聘系统中的候选人，面试，宣讲，校招等等都大不相同。

正确的应用DDD的战略模式来帮助问题的识别和理解，比单纯的应用DDD-Lite要重要得多。

通用语言

限界上下文

上下文映射

思维方式转变

开发者要将思维方式转变成以业务规则优先是一件非常困难的事儿。毕竟经过了多年的训练，特别是抽象思维的训练，开发者很喜欢通用的技巧，比如管道-过滤器，线程池，解析器等等。然而业务规则往往是具体的，而且很多时候，需求变化的方向会破坏掉开发者精心构筑的抽象体系。

然而个思维方式的转变正是成功实施DDD关键所在：愿意和业务人员一起理解沟通，理解业务是实施DDD的第一步。其实每个行业的业务都有很多有意思的地方，我在ThoughtWorks，由于工作性质的原因，可以接触到很多不同的客户，不同的业务。每个项目上，我都很乐于去向业务人员学习，业务在现实世界中是如何运作的：房产中介如何打广告，房东如何付费，房地产广告平台如何从中盈利；无线基站如何建设，工人如何去施工，甚至基站铁塔如何避雷，如何防雨；保单的类型，付费年限，如何分红等等。

每个不同的业务都可以学到很多人们在解决问题时发明出来的新思路，新方法。这些思路和方法未尝不可以反过来应用在软件开发上。

工程实践

敏捷方法

自动化测试

敏捷方法

其实早在敏捷宣言产生的时代，人们就已经发现了客户合作胜过合同谈判。与客户保持高度的合作（最好是业务人员就坐在开发人员旁边），实时的反馈收集并根据反馈进行方向调整都是敏捷方法中倡导的。而DDD更进一步，需要和业务人员一起，定义出领域模型的原型，包括一些白板上的图和代码原型，并根据敏捷方法进行持续的演进。

比如这里提出的一些实践可以比较好的帮助你来实施DDD:

需求的Kickoff（BA，开发，QA一起来明确需求的含义）

结对编程（不限于开发之间的结对，也可能是不同角色间的结对）

代码审视

代码重构

Mini Showcase

回顾会议

通过敏捷实践，我们可以建立起快速的反馈机制，和对变化的响应能力，冗长的流程和不透明的价值流向会导致很多问题。

如果我们承认自己不是全知全能的，需要不断地通过学习来不断的理解业务，那么重构就编程了一件自然而言地、必须做的事情了。通过重构，我们将之前模糊的业务概念清晰起来，将缺失的概念补齐，将代码中的华为到消除。

Mini Showcase强调开发者在完成需求的过程中，不定期的与BA，QA等角色交流、确认。如果有理解不正确的地方，可以尽快发现，然后解决。

自动化测试

另一方面，要保证模型的可理解性，除了Clean Code的一些原则之外，自动化测试也是一个必不可少的工程实践。领域模型在意图表现上需要做到极致，而单元测试/功能测试则以用例的方式将模型用起来。这要求开发者使用实例化需求，行为驱动开发等方法编写实践作支撑。

测试不是为了覆盖率，也不能仅仅只是为了自动化一些手工的工作。在DDD的上下文中，自动化测试更多的是完整表达业务意图的用例。

实例化需求

测试需要以实际用户的角度来编写，并以实例的方式描述。这样即使自动化做不了，这个实例依然是一个很好的文档。当然，为了保证这个文档不过期（和代码实现不匹配），还是强烈建议可以将其自动化起来。

比如这里有个例子，人事经理想要找一些开发人员来分配到项目上，这个找人的过程有两条很简单的规则：

开发人员的技能要和项目的要求匹配

开发人员当前不在项目上（比如当前项目为Beach即为空闲状态）

用Cucumber写的测试看起来是这样的：

Feature: Find employee by skills
  As a staffing manager
  I want to find employee by skills
  So that I know whether we have the staff or we need to hire new ones

迭代开发

软件开发本身就具有很高的复杂度，正如我在上一篇博客里提到的，在项目启动之初，无论是业务专家还是开发者，对软件系统的知识都是非常有限的。迭代式的开发方式更加契合这种复杂度很高的活动。业务人员和开发一起，在建模、实现的过程中会对领域进行深入的学习，并产生新的知识。反过来这些新的知识又会影响模型的进一步进化。

迭代开发的方式可以帮助我们将这个复杂度很高的过程变得平缓一些，而且从一个个小的迭代中学习，并根据反馈来指导新的方向，可以快速的帮助团队建立信心，同时对业务的理解更为深入，使得整个开发过程越来越平顺。

小结

简而言之，要顺利实施DDD，需要至少做到：

明确概念，分清问题域和解决方案域，应用DDD的战略模式

转变思维方式，为业务梳理和理解赋予最高的优先级

通过工程实践来确保落地