拥抱毒瘤 DDD!
牛B的人物,早已经厌倦了中英文混杂,他们更进一步,使用中英文缩写,对普通人进行降维打击。更厉害的,造就新的名词,并科普出去。
有几项技术,我从心底里鄙视和厌恶,但每次在技术方案中,都默默的把它们加进去,而且给足了它们分量。因为它们对于方案的成功与否,起着重要的概念性指导作用。
它们就是中台、低代码,以及DDD。这三个不同领域中的技术,肩负着同样的责任,那就是往死里忽悠。这三个词,很伟大,它们有一个共同点,都是很容易说服非技术但能决策的人员,然后向下铺开,非常具有营销型,是职业经理人和CTO的最爱。也是咨询类公司的最爱。
这些玩意儿,有的可以忽悠大公司,有的可以忽悠小公司,反正谁也别想逃掉。
但毒瘤如果能够为我们带来利益,当然也要拥抱。不要那么死板嘛。
当妖风袭来,比起关上窗子,我们要拥抱它,要投其所好!为什么有的人工资高,有的人升的快!有的人成为了大师!要从根本上想想原因。
概念能够升华体系
你知道么?越是职位高的人,越容易喜欢虚无缥缈的东西。拿古代的皇帝来说,有很多期望与神仙相会的,就被方士骗的死去活来。即使到最后知道被骗了,也只能偷偷的把消息封锁起来。最近看《资治通鉴》,就发现了很多这样的案例。
一来,是他们真的有这种需求;二来,是怕这些事被曝光了丢脸,只能咬牙坚持下去。
地球上没有新鲜事,放到软件行业也一样。当我们把一件东西给神化,赋予它某些超自然的能力,它就能在方士的路上越走越平坦。
如何神化?抓痛点、谈愿景、搞方法论,一般就能够销售成功。
当然,销售成功只是第一步,我们还要避免失败,避免被秋后算账。所以,我们需要把决策者的积极性调动起来,让他认识到自己的不足,羞于承认自己的弱点,我们就算落稳脚步了。只要决策者上了船,他就会想方设法美化它,争取更多的资源,让更多的人上船。
为什么互联网黑话生命力强劲,就是因为它能忽悠,能够升华你的思想,而不是空洞洞的代码。
我这里举个例子。
有一家公司,由于研发的人数有限,但是活儿很多,分散在多个系统之间。研发部门研究出来的结论是:要聚焦,集中力量到核心系统上。怎么办?不能在PPT上干巴巴的写上聚焦
两个字吧,那显得多LOW。
思来想去,突然灵机一动。要不,我们造点名词吧。按照级别,分它个CVP系统、IVP系统、EVP系统。这样,一下子逼格就上升了不少。
看不懂这些名词?看不懂就对了,因为这是我造的,要的就是看不懂这种效果。
看看下面这张图,我们甚至可以赋予它属性,把系统归类到这三类之中。
重要的是,业务系统的聚焦,摇身一变,成为了CVP的重点建设。哈哈,比起一句话就完事的决策,我们这下可以聊很久了。
“教你怎么说话十分钟,等于什么都没说”。这是一种非常重要的能力。
那么,我们就来看一下,这些技术到底是什么?为什么是毒瘤?为什么要拥抱它们。
D不D的D的,有啥区别么
所谓领域驱动,就是根据需求设计系统,这句话本来就是废话。
有Demo代码没?
有Demo代码没?
有Demo代码没?
有Demo代码没?
所有的文章下面,都充满了这样的发问。如果说DDD层只是战略上有用,那它就不应该进入程序员视野,它应该是需求分析师的玩具。DDD应该学学TOGAF、COBIT、CGEIT之类的培训,把眼光放在战略布局上,不要老是想着革程序员的命,搞什么战术。
你要是专心搞搞业务培训证书,你赚你的钱我做我的架构设计,咱们井水不犯河水。但你要把触角伸到我的领域,就会招来像我这样的喷子。
DDD正确的打开方式,就是拥抱它的战略阶段,完全扔掉它的战术阶段。这样做,你会活的很舒坦。原谅我使用“限界上下文”这样的名词来解释一下:你只要把我的服务边界划分清楚了,你管我后面是怎么实现呢,设计模式和架构模式,我的工具箱多的很,并不缺CQRS、事件溯源这样的名词。
DDD的概念最早来源于2004年,这么多年没火,没有标准落地,不是没有原因的。最近几年,有些人发现了技术名词的贫瘠,重新捡起了它,希望它能继续为KPI效力。
我曾痴迷DDD,被它的美好愿景折磨的兴奋无比。买了网课,买了书籍,到最后发现它在浪费我的时间。我恨它。恕我直言,一个难度高,落地难的技术方案,根本没有资格让人分割精力去了解它。
不好意思,没有路转粉。
首先,搞DDD的,都是些卷中卷公司,它不像微服务技术一样,能够找到大量落地的方案。实际上,你几乎找不到任何有价值的参考示例,更别说这些示例之间还相互打脸。它就像是圣经一样,给你说什么是对的,但怎么做,全靠你悟。
为什么你干不了DDD,你的团队干不了DDD?DDD给出了三个主要原因。
对团队的要求较高。画外音,你做不好是你的团队不行 只有复杂的业务使用DDD才能见效。那什么是复杂呢?并没有定论。话外音,你觉得不好用,那是你的业务不够复杂 虽然你用不了DDD,但其中的思想,还是值得借鉴和思考的。画外音,我是万金油,不会让你白学
没有人会承认自己的团队不行,没有团队会承认自己的业务简单,没人能忍受自己的投入就真的肉包子打狗了。DDD通过几个让你不能打脸的理由,瞬间将你绑在了一起。
2020年,花了整整三个月时间,有幸拜读了《实现领域驱动设计》这本书,对其深厚的文字运用水平惊叹拜服。以后,即使一个简单的CRUD项目,我也知道文档应该怎么写了,这本书就是非常好的案例。
你搜一下DDD的文章,不论什么文章,都有一个特点,那就是不能好好的说人话。所有的应用代码,都是一堆无法说服人的垃圾代码。因为开发者和正常的写法一比较,发现自己在找罪受,那为什么要用它呢?
就拿吹的很牛b的六边形架构来说吧。
六边形架构,因为长得像蜂窝,看起来就很靠近绿色的自然界,很高大上。说实话,我到现在都没弄明白六边形架构,八边形架构(没这种东西),三角形架构(没这种东西)之间,到底有何区别,这群名词狂魔为啥选择了6这个数字。
您就直说,复杂的业务逻辑,不应该过多的关注技术等基础设施、但要预留接口就行了,非要整的这么玄乎,一条条蚯蚓一样的线从那腐烂的六边形上辐射出来。觉得很美么?或许老板真这么觉得,因为它像彩虹一样的名词轮,确实能唬住一群蹉B。
不要说ServiceMesh的数据平面和控制平面分割,是靠DDD指导的哦,虽然它概念上靠的上。
下图是google搜索Hexagonal Architecture
出现的一张图。
哎吆,六边形呢?这图怎么整了个10边形?那还是六边形架构么?您忽悠小孩子呢?当我不识数?什么,你又把它叫做洋葱头架构,它们不是一个东西?这样的误解在DDD中比比皆是,我也不想解释,因为它们都是短话长说。这说明了它是一门全面的忽悠方法论,是靠堆概念和黑话起家的,宣传者也不合格。
整个DDD这一套概念,价值观就有问题。或者说作者的本意或许是好的,面向的是复杂业务。结果让这群宣传者和培训一捣鼓,就成了解决问题的必要手段。
但是不好意思,您连起码的顺畅交流都没整好,没资格教别人做架构。
尴尬局面
让人觉得尴尬的是,真正需要DDD的人,并不认同它;不需要DDD的人,被强迫认同它。
DDD最大的价值是梳理业务性需求,将不同的业务领域划分出来,并形成领域之间的接口交互。说个实话,我见过很多咨询公司的大佬,他们对这种想要通吃的方法论嗤之以鼻,更倾向于使用TOGAF之类老牌的业务梳理方法。但条条道路通罗马,最终的领域划分还是能够达成一致。
这些梳理的过程,大部分是业务专家,以及系统架构师的范畴。他们的工作成果,将作为输入输出到技术团队实现。他们需要DDD,但他们并不用。
相比较而言,DDD的战术阶段,毫无价值而言。比如,把数据汇总到宽表或者大数据中心,形成数据“中台”提供交易域、管理域、查询域的分离,我并不需要知道什么CQRS的概念,也能工作的很好。至于实体充血不充血,我本来就是微服务了,业务粒度本来就很小了,要怎么写是我的自由,改造也是我自己的成本,我并不需要按照你那一套来。谈业务和技术的沟通?不好意思,不能沟通而去做业务的团队,我还没见过。
工程师被决策层强迫使用DDD战术书写业务,结果代码更乱,更改更加频繁。但是DDD说,不好意思,不是我的错,是你团队不行。
道理是这个道理,但在现实中,还是有人吹嘘、甚至使用这个东西去改造代码。《微服务架构模式》这本书,甚至有事件溯源和CQRS两个章节,去专门讲解DDD的一些落地的内容。这叫做大师毒害了大师,当然也叫做相互扶持。
恕我直言,如果你信了这些鬼话,大概率会把项目带入死亡。尽信书不如无书,架构是一种权衡,并没有通吃的指导思路。你可以参考,可以思考,但就是不能照搬,因为每个公司的技术前提都不一样。
话虽如此,但当一些概念被吹嘘起来的时候,你不去拥抱它,反而会产生问题。软件行业有两个难题,一个是怎么把复杂的事情简单的汇报,另外一个就是把简单的东西搞复杂。对于前者,主要是描述你构想的可行性。而对于后者,主要的目的就是让人觉得很高大上,很主流,越晦涩越好。前者脚踏实地,后者口吐莲花。
而后者的功效,显然要比前一种有效得多。让人听上去感觉很牛x,但是听不懂,可以获得掌声,也可以体验高高在上的感觉。没人会承认自己的智商不在线,你需要激起这些人的活力。只要有人认同,就可以产生利益。
有些概念,有些人,并不是神,但利益共同体,需要他成为神。这玩意也有信徒,你信么?但软件设计的工具,难道不是合适就用,不合适就扔么?为什么会成为信徒?仅仅是因为上船了而已。
朋友们,在一定程度上,DDD这些概念,与比特币之类的概念,并没有什么区别。这就是信仰的魔力,这就是大师的力量啊!
End
只有像我这样诚实的人,才会偶尔喷一喷。然后转身,把DDD写在了自己的方案上。是的,我可以写上,也可以讨论,也可以思维碰撞,但我永远不会轻易用它。
只有在发广告的时候,我才会把它吹成自己的亲爹。
读者诉苦:Redis 宕机,数据丢了,老板要辞退我
我裂开了,现在都在拼时薪了!日薪比不上人家的时薪!