DDD 项目失败的几个原因

为什么想写这个,主要是感受到同志们的学习高潮,恨不得各种练习,但又遭遇到一些挑战,比如“我想在项目中推行DDD,但担心其他人不配合”,“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年多我没怎么看代码,他们完全不是按照我想象的样子在写代码。

上一篇:IBM全新的存储技术 帮助企业拥抱云及大数据工作负载


下一篇:盘点物联网网络和设备安全的五个误解