牛B的角色已经厌倦了中英文混用。他们更进一步，用中英文缩写来降低普通人的维度。更厉害的是，创造新名词并普及。有几项技术是我打从心底里鄙视和讨厌的，但每次都是默默的把它们加入到技术方案中，并给予足够的权重。因为它们对程序的成功起着重要的概念指导作用。它们是中间平台、低代码和DDD。这三个不同领域的技术肩负着相同的责任，那就是闪烁致死。这三个词太棒了，它们有一个共同点，很容易说服非技术但决策的人员，然后流传下去，非常营销型，是职业经理人和CTO们的最爱。它也是咨询公司的最爱。这些东西有的能糊弄大公司，有的能糊弄小公司。反正谁也逃不掉。但如果癌症能给我们带来好处，我们当然应该拥抱它。不要那么死板。恶风袭来，我们与其关窗，不如拥抱它，做自己喜欢的事！为什么有的人工资高，有的人升职快！有的人成为大师！要从根本上思考原因。1、你知道概念可以升华系统吗？地位越高，就越容易喜欢虚无缥缈的东西。就拿古代的帝王来说吧，很多人指望能见到神仙，却被炼丹师给骗死了。就算知道自己最后被骗了，也只能暗中封锁消息。最近看《资治通鉴》，发现很多这样的案例。一是因为他们确实有这样的需求；二来，他们怕这些事情被曝光，丢了面子，所以只能咬牙坚持。地球上没有新鲜事，即使在软件行业也是如此。当我们把一个东西神化，赋予它一些超自然的能力，它就能在炼金术士的道路上越走越顺。如何神化？抓住痛点，讲愿景，搞方法论，一般都能销售成功。当然，销售的成功只是第一步，还要避免失败，避免跌倒后被套牢。所以，我们要调动决策者的积极性，让他认识到自己的不足，羞于承认自己的不足，我们就会站稳脚跟。只要决策者在船上，他就会想办法美化它，争取更多的资源，让更多的人上船。网络俚语之所以这么厉害，是因为它可以糊弄你，升华你的思想，而不是空洞的代码。让我在这里给你举个例子。有一家公司，由于研发人员有限，但工作量很大，分散在多个系统中。研发部门得出的结论是：聚焦、聚焦核心系统。该怎么办？不能干巴巴的在PPT上写“聚焦”两个字，看起来太LOW了。想了想，我突然有了一个主意。如果没有，让我们发明一些名词。按照级别分为CVP系统、IVP系统和EVP系统。如此一来，武力等级一下子提升了不少。看不懂这些名词？你看不懂也没关系，因为我做到了，我只想看不懂这个效果。看下图，我们甚至可以赋予它属性，将系统分为这三类。重要的是，业务系统的重心突然变了，变成了CVP的重点建设。哈哈，比起一句话来做决定，我们现在可以聊很久了。“教你说话十分钟，等于什么都不说。”这是一个非常重要的能力。那么，让我们来看看，这些技术是什么？为什么会是癌症？为什么拥抱他们。2.D和D有什么区别？所谓域驱动就是根据需要来设计系统。这句话是废话。有演示代码吗？有演示代码吗？有演示代码吗？有演示代码吗？下面的所有文章都充满了这样的问题。如果DDD层只是战略上有用，那么它不应该进入程序员的视野，它应该是需求分析师的玩具。DDD要学习TOGAF、COBIT、CGEIT等培训，注重战略布局，不要老想着程序员的人生，用什么战术。你专心做业务培训证书，你赚你的钱，我做我的架构设计，我们不犯河。但如果你试图进入我的领地，你会吸引像我这样的巨魔。DDD的正确打开方式是拥抱它的战略阶段，彻底抛弃它的战术阶段。做到这一点，你就会过上舒适的生活。原谅我用“限界上下文”这个词来解释：你只要把我的服务边界划分清楚就行了，你管我后面怎么实现。我有很多设计模式和架构模式。缺少CQRS、事件溯源等术语。DDD的概念起源于2004年，这么多年没有流行，也没有标准实现，不是没有原因的。近年来，有人发现了专业术语的荒谬之处，重新拾起它，希望它继续为KPI工作。我对DDD很着迷，它的美好愿景让我无比兴奋。买了网课，买了书，最后才知道是在浪费自己的时间。我恨它。恕我直言，一个难度高、实施难度大的技术方案，根本没有资格让人分心去理解它。抱歉，没有鹿转粉。首先搞DDD的都是中量的公司。不像微服务技术，他们可以找到大量的落地方案。事实上，你很难找到任何有价值的参考例子，更不用说这些例子之间的竞争了。它就像圣经，它告诉你什么是对的，但如何去做取决于你的理解。为什么你不能做DDD而你的团队不能做DDD？DDD给出了三个主要原因。对团队要求高。画外音，如果你做不好，那是因为你的团队做不到。只有复杂的业务才能使用DDD才能有效。那么什么是复杂的呢？没有结论。如果你觉得它不好用，说明你的业务还不够复杂。虽然不会用DDD，但是里面的思想还是值得学习和思考的。画外音，我是??万事通，不会让你白学的。没有人会承认自己团队不好，没有团队会承认自己业务简单，没有人能承担自己的投资，所以他们真的会肉包子打狗。DDD通过几个不让你打脸的理由瞬间把你们绑在一起。2020年，我度过了整整三个月，有幸读到了这本书《实现领域驱动设计》，对其深厚的文笔水平感到惊叹和敬佩。以后哪怕是一个简单的CRUD项目，我都会知道怎么写文档了。这本书是一个很好的案例。搜索DDD的文章，不管是什么文章，都有一个特点，就是说不好人话。所有的应用程序代码都是一堆没有说服力的垃圾代码。因为与正常的写法相比，开发者发现自己在寻找罪恶感，所以为什么要使用它呢？以吹牛的六边形建筑为例。六边形的结构，因为它看起来像蜂窝，看起来很接近绿色的大自然，很高大上。说实话，我一直没弄清楚六边形建筑、八边形建筑（没有这个东西）和三角形建筑（没有这个东西）的区别，为什么这群名词狂人选择数字6。你就这么说吧复杂的业务逻辑不要过多关注技术等基础设施，但预留接口即可。辐射出去。你觉得美吗？或许老大真的是这么想的，因为它那彩虹般的名词轮真的可以吓死一帮白痴。不要说ServiceMesh的数据平面和控制平面切分是DDD指导的，虽然它在概念上依赖它。下图是在google搜索HexagonalArchitecture时出现的图片。嘿，六边形呢？这幅图怎么有10边形的？那还是六边形建筑吗？你在愚弄孩子吗？什么时候数不过来？什么，你称之为洋葱架构，它们不是一个东西？这样的误解在DDD中比比皆是，我也不想解释，因为都是小故事。这说明这是一种综合性的欺骗手段，从一堆概念和俚语开始，宣传者不够格。DDD的整个概念在价值观上存在问题。也就是说，作者的本意可能是好的，是为了复杂的业务。于是，这批宣传人员和培训人员就成了解决问题的必要手段。但是很抱歉，你连最起码的顺畅沟通都没有做到，你没有资格去教别人做架构。3.尴尬的处境让人觉得尴尬的是，真正需要DDD的人却不认同；不需要DDD的人被迫同意它。DDD最大的价值在于梳理业务需求，划分不同的业务领域，形成领域之间的接口交互。说实话，我看到很多咨询公司的大佬对这种什么都想通的方法论嗤之以鼻，更喜欢用老套的业务排序方式，比如TOGAF。但条条大路通罗马，最后的分域还是可以达到的。大多数这些组合过程属于业务专家和系统架构师的领域。他们的工作成果将作为技术团队的输入和输出来实施。他们需要DDD，但他们不使用它。相比之下，DDD的战术阶段就一文不值了。例如，将数据聚合成宽表或大数据中心，形成一个数据“中台”，提供交易域、管理域和查询域的分离。不需要知道CQRS的概念，也能很好的工作。至于实体拥塞不拥堵，我已经是微服务了，业务粒度已经很小了。想写什么是我的自由，改造也是我自己的成本。我不需要按照你的方法。谈谈业务和技术交流？对不起，我还没有见过不会交流但会做生意的团队。工程师被决策层逼迫使用DDD战术写业务，导致代码更乱，变更更频繁。但是DDD说，对不起，这不是我的错，是你的团队做不到。道理是这样的，但是现实中还是有人吹嘘，甚至拿这个东西改造代码。《微服务架构模式》这本书甚至有事件溯源和CQRS两章，讲解DDD的一些落地内容。这叫师父毒师，当然也叫相互扶持。恕我直言，如果您相信这些废话，则很有可能会导致该项目死亡。与其相信书本，不如没有书本。架构是一种取舍，没有万事万物的指导思想。可以参考和思考，但不能照搬，因为每个公司的技术前提都不一样。话虽如此，当一些概念被吹大时，如果你不拥抱它，它就会出问题。软件行业存在两个问题。一是如何把复杂的事情用简单的方式来汇报，二是把简单的事情复杂化。对于前者，主要是描述你的idea的可行性。至于后者，主要是让人觉得高大上、主流，越隐晦越好。前者脚踏实地，后者喷莲花。后者的效果显然要比前者有效得多。听起来很牛逼，但如果你听不懂，也能得到掌声，体会到优越感。没有人会承认他们不够聪明，你需要激励这些人。只要有人同意，就能产生利益。有些观念，有些人，不是神，但利益共同体要求他成神。这东西也有信徒，你信吗？但是软件设计工具不是应该用得上，用得不好就扔掉吗？为什么要成为信徒？只是因为它在船上。朋友们，DDD的概念在某种程度上和比特币这样的概念没有区别。这就是信仰的魔力，这就是高手的力量！
