DDD 项目失败的几个原因

简介: DDD 项目失败的几个原因

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



image.png


image.png


就笔者之所见,一个标榜实践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年多我没怎么看代码,他们完全不是按照我想象的样子在写代码。

相关文章
|
8月前
|
Java Spring
ddd 领域事件 springboot 代码案例
ddd 领域事件 springboot 代码案例
217 0
|
Kubernetes 前端开发 架构师
DDD as Code:如何用代码诠释领域驱动设计?(1)
DDD as Code:如何用代码诠释领域驱动设计?
144 0
|
前端开发 API 网络架构
DDD as Code:如何用代码诠释领域驱动设计?(3)
DDD as Code:如何用代码诠释领域驱动设计?
129 0
|
IDE Java 程序员
DDD as Code:如何用代码诠释领域驱动设计?(2)
DDD as Code:如何用代码诠释领域驱动设计?
196 0
|
项目管理
DDD案例(1):从需求分析到领域分析(4)
DDD案例(1):从需求分析到领域分析(4)
426 0
DDD案例(1):从需求分析到领域分析(4)
|
设计模式 缓存 Java
DDD之代码架构
这是一篇迟到的文章。这其实是我写DDD的第四篇文章。去年11月份左右我在个人网站上写了三篇关于DDD的文章,都是比较偏战略部分的。那个时候我还在一个正在使用DDD的项目上,也是我第一次真正开始深入使用DDD。
556 1
|
测试技术 人机交互 持续交付
DDD 项目失败的几个原因
DDD 项目失败的几个原因
DDD 项目失败的几个原因
|
设计模式 领域建模
DDD的模式与实践案例(1)
DDD的模式与实践案例(1)
951 0
DDD的模式与实践案例(1)
|
设计模式
DDD的模式与实践案例(2)
DDD的模式与实践案例(2)
614 0
DDD的模式与实践案例(2)
|
测试技术
DDD的模式与实践案例(3)
DDD的模式与实践案例(3)
498 0
DDD的模式与实践案例(3)