厉害的技术人，早已不满足于中英文混杂的表达，他们更进一步，开始使用中英文缩写来建立认知壁垒。更甚者，则是直接创造新的技术名词并加以推广。
有几项技术，我内心其实颇为抵触，但在实际的技术方案设计里，却总是默默地把它们加进去，并且给予相当的分量。原因无他，这些概念对于方案能否通过评审、能否获得资源，往往起着关键的“指导”作用。
它们就是中台、低代码，以及DDD（领域驱动设计）。这三个来自不同领域的概念，却肩负着相似的“使命”——极富说服力，尤其擅长影响那些有决策权但技术背景不深的管理者。它们自上而下推行开来，充满了营销色彩，是不少职业经理人和CTO的心头好，自然也深受各类咨询公司的青睐。
这些概念，有的能“忽悠”住大公司，有的能“打动”小公司，似乎谁都难以完全避开。
但话说回来，如果这些“争议点”能为我们带来实际利益，当然也要学会拥抱。别太死板嘛。当某种“技术风潮”袭来，比起关窗抵抗，不如顺势而为。为什么有些人升职快、薪资高、能成为“技术布道者”？我们需要从更根本的层面去思考。
概念如何“升华”技术体系
不知道你发现没有，职位越高的人，往往越容易被一些宏大而抽象的概念吸引。就像古代很多皇帝渴望长生不老，从而被方士骗得团团转。即使最后发现自己上当了，为了颜面也得封锁消息，咬牙坚持下去。
历史总是惊人的相似，软件行业也不例外。当我们把一项技术“神化”，赋予它某种解决一切问题的超能力，它就能在布道的路上越走越远。
如何神化？抓住痛点、描绘愿景、套用方法论，通常就能“销售”成功。
当然，销售成功只是第一步，我们还得避免项目失败后被“秋后算账”。因此，关键是要调动决策者自身的积极性，让他意识到自己的“认知不足”，从而羞于承认这个选择是错的。只要决策者上了“船”，他就会自发地美化它、争取更多资源，并拉更多人上船。
为什么互联网“黑话”生命力顽强？正是因为它能进行概念包装，能够“升华”你的思想体系，而不是仅仅停留在枯燥的代码层面。
举个身边的例子。
有一家公司，研发人手有限，但业务线繁多，系统分散。研发团队得出的结论是：需要聚焦，集中力量建设核心系统。但PPT上总不能只干巴巴地写“聚焦”两个字吧？那显得太没水平了。
思来想去，灵机一动。不如，我们造几个新名词吧。按照重要性，将系统分为CVP（核心可用产品）、IVP（重要可用产品）、EVP（外围可用产品）三类。瞬间，方案的“逼格”就上来了。
看不懂这些缩写？看不懂就对了，因为这是我创造的，要的就是这种“信息差”效果。
看看下面这张图，我们甚至可以为每类系统赋予清晰的属性和建设原则。
这样一来，“聚焦核心业务系统”这个朴素的诉求，就华丽转身为“CVP系统重点建设”。比起一句干巴巴的结论，现在我们有了可以展开讨论半小时的“方法论”。
“如何把十分钟的话说得像什么都没说，却又显得高深莫测”，这本身是一种重要的职场能力。
那么，DDD到底是什么？它为何充满争议？我们又为何不得不与它共舞？
DDD：战略与战术的割裂
所谓领域驱动设计，其核心思想是根据业务需求来驱动系统设计。这句话本身，听起来像是一句正确的废话。
于是，无数学习者发出了灵魂拷问：有Demo代码吗？有可落地的示例吗？
如果DDD的价值仅仅停留在战略层面（比如划分领域、界定上下文），那它本应是业务分析师和架构师的工具，而不该过分侵入程序员的实现细节。DDD或许应该向TOGAF、COBIT这类企业架构方法论看齐，专注于战略布局，而不是老想着“革”程序员的“命”，在战术层面搞出各种复杂模式。
你如果只搞搞战略培训与认证，赚你的知识付费，我做我的技术架构，咱们井水不犯河水。但一旦它的触角伸向代码该如何写，就难免招来批评。
个人认为，DDD相对正确的打开方式是：拥抱其战略设计部分，果断抛弃或谨慎参考其战术实现部分。这样做，你会轻松很多。用DDD自己的术语来说：只要用“限界上下文”把我的服务边界划分清楚就行了，至于我内部是用传统三层架构还是别的什么模式，那是我自己的事。我的架构模式工具箱里选择很多，并不缺CQRS、事件溯源这些听起来时髦的概念。
DDD的概念早在2004年就被提出，这么多年不温不火，缺乏公认的标准落地实践，不是没有原因的。最近几年，有些人或许觉得技术名词库需要翻新，又重新拾起了它，希望它能继续为KPI服务。
我曾经也痴迷过DDD，为其描绘的美好蓝图兴奋不已。买了线上课，啃了大部头，最终却发现它更多地是在消耗我的时间。我必须坦言，一个理解成本高、落地难度大、且缺乏公认最佳实践的方法论，不值得让大多数团队all in去实践。
首先，真正在深入实践DDD的，往往是那些“卷中卷”的公司。它不像微服务那样，有Spring Cloud、Dubbo等成熟框架和大量实践案例可供参考。事实上，你很难找到一份公认权威、可直接参考的DDD代码示例，而且不同的示例之间可能互相矛盾。它有点像“圣经”，告诉你什么是对的，但具体怎么做，全靠个人“悟性”。
为什么你的团队做不好DDD？DDD的支持者通常会给出三个“无懈可击”的理由：
- 对团队要求高。（潜台词：做不好是你团队能力不行）
- 只有复杂业务才能体现其价值。（潜台词：你觉得没用？那是你业务太简单）
- 即使无法全盘落地，其思想也值得借鉴。（潜台词：我怎么都有理，你不会白学）
没有人会承认自己团队不行，也没有团队会承认自己业务简单，更没人能接受自己的投入血本无归。DDD通过这套让你无法反驳的逻辑，巧妙地完成了“绑定”。
2020年，我花了三个月精读《实现领域驱动设计》一书，对其深厚的、堪比哲学著作的文字功底深感“佩服”。至少，以后即便是写一个简单的CRUD项目文档，我也知道如何“拔高”了——这本书就是个绝佳的范文。
如果你搜索DDD相关的文章，会发现一个普遍特点：很难好好说人话。而文中的示例代码，大多看起来像是一堆为了迎合概念而生造的“玩具”，与实践中高效、清晰的代码相去甚远。因为开发者一旦对比就会发现，这是在自找麻烦，那为何要用它？
就拿被吹捧的“六边形架构”来说吧。
六边形架构，因为形状像蜂窝，听起来就很贴近自然，很高大上。说实话，我至今没完全搞明白六边形架构、洋葱架构、整洁架构之间本质的区别到底有多大，以及命名者为何对“六”这个数字情有独钟。
您就直接说“复杂的业务逻辑应该与基础设施解耦，并通过端口适配器与外界交互”不行吗？非要弄得如此玄乎，画一堆线从那个六边形里辐射出来。这真的很美吗？也许老板觉得美，因为这种像彩虹轮一样的概念图，确实能唬住不少人。
难道Service Mesh的数据平面和控制平面分离，也是靠DDD指导的？虽然概念上似乎能扯上点关系。
下图是Google搜索“Hexagonal Architecture”时常见的一张示意图。
等等，说好的六边形呢？这图看起来有十个边不止吧？这还能叫六边形架构吗？您这是忽悠我不识数？什么，您又把它叫“端口适配器架构”或“洋葱架构”？它们不是一个东西？这种概念混淆、名词滥用的情况在DDD的传播中比比皆是，我也不想过多解释，因为它们本质上是把简单问题复杂化的话术。这恰恰说明它是一套建立在大量概念和“黑话”之上的方法论，甚至连布道者自己也未必完全统一。
整套DDD的话语体系，其价值观可能就有些偏差。或许原作者Eric Evans的初衷是好的，面向真正复杂的核心领域。但经过各路培训机构和文章作者的“加工”，它似乎成了解决一切软件设计问题的“银弹”。
抱歉，一个连清晰、无歧义的交流都无法保证的方**，恐怕没有资格教别人如何做好架构。
现实的尴尬
一个尴尬的现实是：真正需要DDD战略思维的人（如业务架构师），可能并不使用这套术语；而并不急需DDD战术的研发团队，却被强制要求使用。
DDD最大的价值在于梳理复杂业务，划分不同的领域边界，并定义领域间的交互契约。说实话，我接触过一些顶尖咨询公司的专家，他们对这种试图“通吃”的方法论往往不以为然，更倾向于使用TOGAF这类经典的企业架构方法。不过条条大路通罗马，最终对业务领域的划分结果可能是相似的。
这些梳理工作，主要是业务专家和系统架构师的职责。他们的产出（领域模型、上下文映射图）会作为输入交给技术团队实现。他们需要的是DDD的战略核心思想，而非其具体的代码战术。
相比之下，DDD的战术实现部分，在很多时候价值存疑。例如，我需要将数据聚合到宽表或数据平台，形成供不同业务域使用的数据服务，我未必需要知道“CQRS”这个概念也能做得很好。至于实体应该是“贫血”还是“充血”，在微服务架构下，服务粒度已经足够小，内部怎么写是我的自由，改造的成本也由我自己承担，我为什么要被一套固定的战术模式束缚？谈业务与技术的沟通问题？不好意思，一个无法与业务方顺畅沟通的研发团队，我还没见过。
工程师被决策层强迫使用DDD战术编写业务代码，结果可能导致代码更加晦涩、变更更频繁。但此时DDD方法论可以说：这不是我的问题，是你团队理解不到位或执行力不行。
道理是这个道理，但在现实中，依然不乏鼓吹甚至试图用DDD战术大规模改造现有系统的声音。《微服务架构模式》这类权威书籍中，甚至专门用章节讲解事件溯源和CQRS，这像是“大师之间的相互背书”。但请恕我直言，如果你完全照搬这些模式，有很大概率会将项目引入泥潭。尽信书不如无书，架构的本质是权衡，没有放之四海而皆准的银弹。你可以参考，可以思考，但绝不能生搬硬套，因为每个公司的技术栈、团队能力和业务上下文都千差万别。
拥抱，但保持清醒
话虽如此，当一个概念被炒热并形成风潮时，逆势而为反而可能让自己陷入被动。软件行业有两个经典难题：一是如何把复杂的事情简单明了地汇报清楚；二是如何把简单的事情阐述得复杂深奥。前者关乎项目的可行性论证，需要脚踏实地；后者则关乎“包装”与“影响力”，需要口吐莲花。
而后者的效果，在很多时候比前者更“立竿见影”。说一些让人感觉高大上但又听不懂的话，更容易获得掌声和资源。很少有人会当众承认自己“没听懂”，你需要做的就是激发这种“不明觉厉”的认同感。只要有人认同，利益链条便能运转。
有些概念，有些人，并非天生是“神”，但利益共同体需要他们成为“神”。你相信技术设计也有“信徒”吗？软件设计本应是实用主义的工具，合适就用，不合适就弃，为何会产生信仰？无非是“上船”之后，便难以轻易回头了。
在一定程度上，DDD这类概念，与某些充满信仰色彩的“数字资产”有着相似之处。这或许就是概念的魔力，也是“大师”的影响力所在。
像我这样“实在”的人，偶尔会站出来吐槽几句。但转过身，我可能还是会把“DDD”三个字写进技术方案里。是的，我可以写，可以讨论，可以进行思维碰撞，但我内心会对它的战术部分保持警惕，不会轻易在核心业务代码中全盘套用。
毕竟，只有在需要“营销”自己或方案的时候，我才会把它吹得天花乱坠。对于日常开发而言，保持简洁、清晰和高效，才是对团队最大的负责。技术概念的喧嚣终会过去，而稳定交付价值的系统才是根本。如果你想与其他开发者交流类似架构设计中的权衡与心得，不妨来云栈社区逛逛，这里聚集了许多乐于分享和探讨的一线工程师。
发表于 18 小时前
|
查看: 1|
回复: 0
