DDD到底是不是毒瘤？

那些自视甚高的人早已不再忍受中英文混杂。而他们又进一步开始采用中英文缩写，并向大众实施降维打击。特别厉害的则创造出新的名词，并向公众普及。

我对这些技术怀有深深的抵触情绪，在任何项目中都会刻意避免提及或使用它们。然而，在构建系统的技术方案中不厌其烦地将它们纳入其中，并赋予了它们同等的地位。因为这些技术在方案的成功与否方面扮演着至关重要的角色。

这三者指的是中台架构、低代码开发及Domain Driven Design（DDD）方法。这些不同领域的技术和工具都承担着类似的使命——即尽可能地……成功。这些术语确实具有重要意义，并且能够有效吸引那些虽然不具备专业技术背景但具备决策能力的人。它们之间的一个共性便是能够在商业环境中极具吸引力地被应用与推广，在职业经理人、CTO以及咨询类公司等场合尤为受欢迎。

一些工具不仅能够在大型企业发挥作用……而另一部分则能够在小型企业发挥作用……因此无论是在大型企业还是小型企业……都无法逃脱它们的影响。

但毒瘤如果能够为我们带来利益，当然也要拥抱。不要那么死板嘛。

当妖风突袭而来时，在仅仅依靠关闭窗户之外，请允许我们接纳它的影响，并采取相应的措施。我们为何会观察到有些人拥有较高的收入、更快的晋升速度以及最终成为行业翘楚？这不禁让我们必须从根本原因入手分析其中的规律和机制。

概念能够升华体系

你是否知道？越是有地位高的人就越容易迷恋于玄幻莫测的事物呢？以古代皇帝为例吧！有许多人期望能与神仙会面的愿望都被方士所欺骗，并惨遭陷害致死。即便最后才了解到真相后也只能暗中封锁这些秘密消息。最近翻阅《资治通鉴》一书时，则会发现有许多这样的案例存在啊！

一者，则由于他们确实存在这一需求；二者，则因担心此类事件被公开后会损害自身形象而不得不持续努力。

世界本质上并不存在真正的新鲜事物。同样适用于其他领域。当我们对某件事物进行过度吹捧和象征化解读时（例如将其神化），赋予其超越其本质的特殊属性时（即赋予它某些超自然的能力），它就会沿着通向成功的道路稳步前行。

如何神化？抓痛点、谈愿景、搞方法论，一般就能够销售成功。

毫无疑问，在商业活动中取得销售成功仅仅是第一步。我们必须防止失败的发生，并不被"秋后算账"所困扰。调动决策者的积极性是必要的——让他们意识到自身的缺陷而不愿承认自己的弱点。做好这些准备就可以稳固地站住脚跟。只要他们上了船，则会努力美化它并争取更多的资源与支持。

因为互联网术语的生命力之所以顽强不屈，在于它巧妙地让人困惑，并非仅仅是充斥着令人迷惑的技术术语和晦涩难懂的专业术语。

我这里举个例子。

一家公司面临研发力量有限却工作量繁重的问题，在各个子系统间分配了大量任务。经过深入研究后得出结论：需集中力量于核心系统上。该怎么处理呢？切忌在展示材料中仅以'专注'两个字来概括。

苦思冥想间忽然间萌生出了一丝灵感。何不妨研发一些新概念呢？根据等级划分设立CVP体系、IVP体系以及EVP体系。如此一来不知是否能将整体的逼格跃升一个台阶？

对这些名词感到困惑吗？其实并不可怕。因为我特意设计了它，并且正是这种难以理解的效果才是它的目的所在。

看看下面这张图，我们甚至可以赋予它属性，把系统归类到这三类之中。

核心关注点在于业务系统资源的关注转变成CVP的重点方向。有趣的是，在简短直接的决策之外，我们拥有了更多交流机会。

“教你怎么说话十分钟，等于什么都没说”。这是一种非常重要的能力。

那么说来，我们来探讨一下这些技术具体是什么？为什么说是难点？为什么要接纳它们？

D不D的D的，有啥区别么

所谓领域驱动，就是根据需求设计系统，这句话本来就是废话。

有Demo代码没？

有Demo代码没？

有Demo代码没？

有Demo代码没？

在所有文章下方的部分中都充满了这种类型的问题。如果仅从战略层面来看的话，则DDD层并不适合被程序员接触到；因此它更像是需求分析师使用的工具或玩具。为了提升整体战略规划能力,DSD（Domain Specific Modeling）应当学习相关的培训课程,将注意力集中在整体战略规划上,不应总是试图削弱程序员的工作效率,而应避免涉及战术层面的工作,以免适得其反的作用。

如果你专注于从事业务培训证书相关的工作，并且专注于架构设计领域的发展，则咱们之间相互独立互不影响。但是如果你试图拓展到我的领域，则这将导致一些不和谐的声音出现。

采用DDD方法论进行系统设计时, 应该首先重点关注其战略层面, 忽视其战术层面即可获得极大的舒适感。为了避免混淆, 在此我对术语进行说明: 明确界定服务边界是首要任务, 无需关注具体的实现细节, 设计模式与体系架构模式是两个核心概念, 这些概念属于基本工具库范畴, 并非难以处理的问题。

起源于2004年的概念如今已未见传播，在标准化实施方面也未能成功落地，并非完全没有阻碍因素的存在。近年来有观点指出技术术语资源匮乏的现象愈发明显，在这一背景下一些人重新唤起了对DDD的关注，并期待这一概念能继续服务于KPI目标。

我对DDD产生了深深的迷恋状态，在于它的理论体系令人难以捉摸且难以实施。于是乎我就购买了一系列相关的课程视频和书籍资料，在经过长时间的学习后才发现这花费了大量的时间和精力。后来不得不坦白地说：我对这种既高又难的技术方案感到极度不满与敌意——觉得它们根本不值得占用大家的时间去深入研究探索

不好意思，没有路转粉。

在搞DDoS防护方面一直是行业内的难点与痛点，在这种情况下

为什么你干不了DDD，你的团队干不了DDD？DDD给出了三个主要原因。

对团队的要求较高。画外音，你做不好是你的团队不行

仅适用于复杂的业务场景中使用DDD方能达到预期效果。
那么什么才算作'复杂'呢？
没有统一定义。
补充说明一下吧？你认为DDD难以应用到您的业务中去吗？

即使无法直接应用DDD；但其理念仍然具有重要的借鉴价值；话外之音：我也充当着万金油的角色；让你无需付出任何努力就能掌握这项技术

没有任何团队会自认为能力不足,也没有任何组织愿意自认业务过于基础,没有人能够容忍投入却换来糟糕的结果。一旦采用DDD的方法,凭借几个有力的证据,迅速地将所有相关人员凝聚成一股强大的合力。

在2020年的那段时间里，在此期间我特意花费了三个月的时间静心研读了《实施领域驱动设计》一书。我对书中所蕴含的深刻写作功底深感钦佩。从那以后，在撰写诸如CRUD这类普通的开发项目时

查阅一下DDD的相关文章会发现一个显著的问题：所有应用代码都难以被理解。因为开发者在与常规开发规范对比时感到困惑，并认为使用这种技术会让他们陷入困境。

就拿吹的很牛b的六边形架构来说吧。

六边形架构因其外观上贴近自然环境而显得极为高雅。老实说，在我看来六边形架构与其他多边形结构（如八边形、三角形等）之间究竟有何区别尚不明确——这些术语真让人费解！为什么会选择这个数字呢？

您就直说吧！
复杂的业务逻辑不必过分纠结于技术和相关基础设施，
而关键在于留下足够的接口。
非得搞得那么玄乎，
那些连接就像从腐烂六边形延伸出令人不安的分支。
觉得很美吗？
或许老板真的这么认为，
因为这些结构就像是彩虹一样的名词轮，
确实能唬住一群自以为高人一筹的人。

不提ServiceMesh的数据平面与控制平面的分离主要依据的是DDD理念呢？尽管在概念层面上有一定契合度。

下图是google搜索Hexagonal Architecture出现的一张图。

咦？这个图上标着"六边形"吗？怎么把整个图形划分成了十边形呢？也就是原来的六边形架构吗？难道您是在给小学生普及知识吗？可我是个文盲！难道又把它称作"洋葱头架构"吗？这两个概念其实是有区别的。这样的误解在DDD中广泛存在不胜枚举的情况我不想再深入讨论这个问题因为其 approach tends to use concise jargon for complex ideas

整个DDD这套理念的价值存在争议。然而作者可能有意图良好，在应对复杂业务场景时试图引入这一方法论框架。但这种做法反而导致了这些宣传活动和培训工作被过度使用以解决关键问题。

但是不好意思，您连起码的顺畅交流都没整好，没资格教别人做架构。

尴尬局面

令人感到尴尬的是那些实际上需要采用DDD技术的人，并不认可这一方法；而那些不需要采用DDD技术的人，则被迫接受这一方案。

其核心优势在于系统性地识别和整理业务需求，并将其划分为独立的功能模块。实现各模块间的交互与通信以促进信息流高效运转。说实话调研发现多数行业顾问专家普遍对其主张持否定态度认为这种方法过于理想化难以适应实际工作场景。而 TOGAF 等经典方法体系则因其科学性和可操作性赢得了广泛认可尽管如此在实际应用中无论采取何种方法在最终的设计阶段都能达成一致

这类梳理的过程主要属于业务相关领域内的工作内容。这些工作成果既作为输入也作为输出传递给技术团队来完成开发与维护工作。然而，在实际工作中这些业务专家和系统架构师也需要应用数据驱动开发的方法论（DDD），但实际上并未采用。

相较于而言, DDD作为其战术阶段,没有任何实用价值。例如,将数据整合至宽表或大数据中心,构建出所谓的"中台",实现了交易域与管理域及查询域的独立,这种做法无需了解CQRS的相关概念依然能够有效运作良好。至于实体是否充血的问题,由于我们已经采用微服务架构,业务粒度本就非常小,对于如何定义"充血"与否其实并不重要;即便有需求也完全可以自行定义边界,进行相应的功能划分及接口设计,这完全属于我的自主权范畴,无需按照特定框架进行标准化配置。如果非要谈论业务与技术如何实现有效衔接的话？对不起,这种无法有效沟通而导致无法开展业务的情形并不存在于我的工作实践中。

工程师被迫采用DDD战术来记录业务流程，在此过程中代码变得混乱，并且频繁发生变更。但DDD回应道，并非是我的过错而是你的团队出现了问题。

这个道理本身就是一个真理，在现实中却有人妄加吹捧甚至将其作为改造代码的工具加以运用。《微服务架构模式》这本专著中就专门设有事件溯源和CQRS两个章节来系统阐述DDD的相关实践内容。这无异于大师误入歧途有之亦或是相互滋养之故。

让我直抒胸臆：我的看法是，在你接纳这些无关紧要的言论时

即便如此，在某些概念被过度吹嘘的情况下（即被夸大宣传），若你不主动接纳它，则可能会引发问题

而后者的功效相较于前一种要显著得多。让人听起来显得很有气势吗？然而听起来却难以真正理解其深意。不仅可以赢得热烈的掌声呢？而且还能体验到一种居高临下的愉悦感受。很少有谁会自认为自己的智商在线吧？你是否应该激发这些人的潜能和活力呢？这样就能带来实际的利益回报了呢！

有些概念并不是"神"类存在,但利益共同体确实需要这些人承担起某种责任与使命。这个东西也有忠实者,你是否信任他?软件设计的工具并非只要合适就可以使用;它们可能需要特定条件才能发挥作用,仅仅因为适合并不意味着就能充分运用其潜力。为何会接受这样的角色?不仅仅是因为被纳入其中了。

在某种程度上而言，在某些情况下（DDD）这些概念，并没有明显的区别。这正是信仰的力量所在。

End

只有像我这样诚实的人才会偶尔表达自己的意见随后转身将DDD记录在其方案中也是情有可原的做法是吧我也能够进行相关的讨论和思维碰撞但最终我会放弃这种想法毕竟DSD不是适合我的选择

原文链接：https://juejin.cn/post/7024025943668686885

如果你觉的本文对你有帮助，麻烦点赞关注支持一下