DDD 项目失败的几个原因

为什么想写这个，主要是感受到同志们的学习高潮,恨不得各种练习，但又遭遇到一些挑战，比如“我想在项目中推行 DDD，但担心其他人不配合”，“DDD 门槛太高，概念多”…

就笔者之所见，一个标榜实践 TDD 的项目要不是口号，噱头，要不就失败了，如同要推行 DDD 的一样。项目不是兵器的练兵场，首先要回到“问题域”，要解决什么问题。

一个以推行 DDD 为目标的项目，总觉得有点慌。

就笔者之所见所闻，有 1 个典型的推广 XXX 的 case。

一个是某司的一位空降 boss，是一位有创派别的国内“敏捷”专家。当然，敏捷专家几乎都耻于谈敏捷 ，这样也就和其他人谈的“敏捷”无法区分开去。空降 boss 一来就感觉到这个团队在代码匠艺 、发布、甚至设计抽象都存在某些不足，于是大谈敏捷实践和各种老外前辈云云，但却被团队吐槽，因为那会这群码农最关心的是“生存问题”，去总部找活回来干的问题 。几个月后这位 boss 转变了思路，通过抓稳定迭代的 release，促进快速反馈“挽尊”，此是后话。

这个 case，让人懂得了 一个道理，一位病人发烧了，医生可以先采取措施让他退烧，然后治疗。病人并不喜欢医生跟他讲中西医区别，药理知识。第二个道理就是，鸡蛋好吃，你非要去分辨是那只鸡下的蛋，并无多大必要。

团队员工的期待是空降老板给我们指方向，找活干，加薪而不是推广敏捷 。

同理，江湖上流传着这样的说法：

老板看问题的视角是，“这个需求很简单，怎么实现我不管”。

某些技术人员的视角可能是，“十八般武艺都用，至少面试用得着”。

另外很诡异的一个点在于，人类对于所谓 “建议”往往听不进去，然后总会找到一堆来证伪，然后又乐此不彼的“学习着”，争论他认为对的观点…

笔者自己也做过推广 XXX 的事情，持续集成。这东西大家都知道，我们之前有一个简单的规约，就是每天下班前的构建要绿色 ，单元测试和接口测试都得通过。好些同学怨声一片，代码都写不完，干嘛还要去写测试代码？尤其是之前测试代码覆盖率巨低的系统，几百个测试 case 不通过的系统 …

采取简单粗暴的每天强制的方式，存量用例设定计划治理，研发同学不情愿的被要求每天跑 CI…在大显示屏的曝光和强迫之下，持续了半年多… 后来有项目团队主动分享 CI 带来的好处，测试代码在他们后面的重构过程中发挥了作用，心里有底多了。

这个故事让我“自以为是”的懂得了第二个道理，让人懂得或者转变是很难的，猴子自己上树和抽猴子屁股上树的区别。如果你拿着香蕉在猴子面前晃，就不一样了。

Greg Young 先生有一个 presentation ，主题就是“

7 Reasons Why DDD Projects Fail“，简单总结 DDD 失败的要点：

Lack of intent（缺乏意图）

Anemic Domain Model（贫血模型）

DDD-Lite

Lack of isolation （缺乏隔离）

Ubiquitous what?

Lack of refinement（缺乏完善）

Proxy Domain Expert (Business analyst)

笔者稍微谈一下自己的理解。

1、首要解决通用语言 UL(Ubiquitous Language 问题，统一域语言。

张逸老师指出，统一语言是提炼领域知识的产出物，获得统一语言就是需求分析的过程，也是团队中各个角色就系统目标、范围与具体功能达成一致的过程。使用统一语言可以帮助我们将参与讨论的客户、领域专家与开发团队拉到同一个维度空间进行讨论，若没有达成这种一致性，那就是鸡同鸭讲，毫无沟通效率，相反还可能造成误解。因此，在沟通需求时，团队中的每个人都应使用统一语言进行交流。

可以想象一下，做支付、银行、电商行业的朋友在谈及记账、清算、结算、核算这些词的时候是否是一个明确统一的含义。一旦确定了统一语言，无论是与领域专家的讨论，还是最终的实现代码，都可以通过使用相同的术语，清晰准确地定义领域知识。重要的是，当我们建立了符合整个团队皆认同的一套统一语言后，就可以在此基础上寻找正确的领域概念，为建立领域模型提供重要参考。

2、没有基于通用语言建立的所谓的聚合，实体，值对象，只能算是 DDDLite，只是技术层面的一种设计方式。

3、要解决好隔离问题，则需要以一种最宏观的角度去对“问题域”进行拆分，来划分“界限上下文”，最终形成一个具有俯瞰视角的“上下文映射图”。这里特别说一下“界限上下文”和问题域、以及服务谁，产生什么价值息息相关。比如一个采用第三方支付（支付宝）的网站，并不对支付宝背后的网联，以及银行渠道进行建模。

4、refinement 的问题

架构腐化见怪不怪，如何领域层腐化了就“烂到跟上”。笔者见过一个系统，初期磨拳搽掌，建造者经验丰富，算是很成功的开端。但是若干年后这个系统 domain 层的代码和当初的领域模型图大相径庭，面目全非。持续的 refinement、保鲜非常重要。

另外，前几天和一位 TL 聊天，他说，我很注重代码追求的，为什么 1 年多我没怎么看代码，他们完全不是按照我想象的样子在写代码。

本文转载自技术锁话公众号。

原文链接：https://mp.weixin.qq.com/s/39Xqd9bVtTAGzXn1B_vxkg