阿俊 2021-11-4 13:11
您发的第八章有一个调查一篇DDD文章提到几个类，我留意看过的文章和演讲，是像您说的那样！我还发现作者除了TW公司的人，还有大部分是互联网公司，而且都会提到微服务。我想问您的问题是，是不是互联网更适合用DDD，微服务架构更适合用DDD？
UMLChina潘加宇
你说的这个问题很有意思。我没有统计过你说的作者的情况，不过印象里和你说的差不多，印象最深是"美团抽奖"。
最近几年的DDD宣传主要是由Thoughtworks公司发起，所以Thoughtworks员工或前员工写文章或演讲多很正常。宣传建模是好事。
针对"是不是互联网更适合用DDD"，我说说我的观点：
（1）你有没有发现，"互联网"也"更适合"用"敏捷"。
《软件方法》第8章也提到：
互联网的兴起带来了这样一种系统：这种系统功能很简单，开发这种系统时需要思考的领域逻辑很少，但是这样的系统可以通过互联网让非常多的人使用，问题的关键变成了"如何在大用户量下保持性能"。
很多开发人员就进入了类似的"互联网公司"，开发或维护类似的系统。因为不需要剖析复杂的领域逻辑，开发人员有没有掌握分析的技能已经无所谓，于是，很多打着"敏捷"旗号的"方法"就在这类公司大行其道，导致软件开发人员的分析能力普遍退步。
经常有人和我说，潘老师，敏捷这一套做工厂管理系统之类的可能不太行，但不得不承认，做互联网很管用噢！
当然管用了！
有个巫医发明了一种治疗方法。他坦言，我这个方法对付癌症可能不太行，但对付感冒很管用噢！你不信，找个感冒患者来！
感冒患者找来了，医生让患者躺在一张绘有八卦图案的方桌上，然后绕着患者绕了八八六十四圈（看到没，他也是有一套方法的！），然后对患者说，回去该吃吃该喝喝，五天之内就好了！
果然，患者好了。
医生四处宣传他的治疗方法，由于此方法简单易学，迅速收获了大批粉丝。
更多内容参见我之前写的文章：互联网公司的很多"建模体会"没有价值。
（2）某些"DDD实践"实际上就是另一个"敏捷"
既然以"领域驱动设计"为名，按道理应该是领域逻辑越复杂的系统越需要"领域驱动设计"，对吧？
如果比较领域逻辑的复杂程度，许多"互联网系统"肯定排不上号。"互联网系统"的用户多，而用户多的系统，往往要做减法，功能取公约数。
例如，微信应该是目前用户最多的应用。如果有微商希望微信提供"美化营销话术"的功能，能根据对方的工作性质、性格等美化发过去的信息，让其更容易打动对方......张小龙肯定理都不理。
当然，第三方厂商可以为这些特定人群开发相应的微信小程序，那是另外的应用了。
美团比微信功能更多，领域逻辑更复杂，相应的，用户量没有微信多。如果身体有某种特殊疾病的食客希望美团提供"健康检测"功能，检测所点的外卖是否会恶化食客所患的疾病，美团估计也是不会做的，为了极少数人添加大多数人不需要的功能，不值得。
以上不是说微信和美团的开发用了"领域驱动设计"，而是举例说明用户多的时候，功能的增加是很谨慎的。
而为特定行业，甚至为某个特定行业的某个特定机构的工作定制的系统，往往功能更多、领域逻辑也更复杂。
我去过一家物探公司讲课，公司的同学介绍，一些物探软件或设备是被"卡脖子"的，只能自己研发。
而微信、美团是不会被"卡脖子"的，这样的系统做起来并不难。微信就是模仿的米聊，后来还有易信、来往......。微信的对手们之所以在竞争中落败，原因不是软件开发本身，而是资源、营销等方面。
啰嗦这么多，意思是：
某些"DDD实践"为什么喜欢挑"互联网"下嘴，原因可能和上面所说的某些"敏捷"一样，实际上这副药治不了复杂的病，只好挑感冒病人来治。
从这个角度说，"互联网"（感冒病人）更适合某些"DDD实践"，是正确的。