概念能够升华体系
D不D的D的,有啥区别么
尴尬局面
总结
有些人为了降低对普通人的难度,使用了中英文缩写,这种现象越来越普遍。甚至有些人创造新词,并向外界普及。
我曾经对一些技术深感厌恶,但每次在方案中都默默地加入了它们,因为它们对方案的成功起到了重要的指导作用。这些技术包括中台、低代码和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这些概念,与比特币之类的概念,并没有什么区别。这就是信仰的魔力,这就是大师的力量啊!
总结
作为一个诚实的人,我认为在解决问题时,一定要坦诚相待。虽然DDD是一个有争议的话题,但在适当的情况下,它可以成为一个强有力的工具。在我的经验中,我发现通过DDD方法可以更好地理解和设计复杂的系统。因此,我鼓励我们在适当的时候探讨和使用DDD方法,并且不必害怕不了解或试图避免它。与此同时,我们也应该认识到DDD方法并不是万能的,它只是我们工具箱中的一个工具,我们需要根据具体情况进行判断和选择。