DDD领域驱动设计批评文集做强化自测题获得“软件方法建模师”称号《软件方法》各章合集团队里有人鼓吹领域驱动设计一名有着严谨思维的开发人员可以怎么做首先我们要了解DDD圈子鼓吹的套路。以下文字摘自《软件方法》**********其中的代表就是“领域驱动设计”。在[1.5.4.1 偷梁换柱]中已有描述把比较难、懒得学的建模方法归为“传统方法学”把“领域驱动设计”吹捧为“新一代方法学”这些开发人员在谈论时把焦点放在“新一代”或革命性、划时代上心照不宣地假装自己对“传统方法学”已经熟悉到不屑一谈了。所以就出现了这样的诡异现象既然以“领域驱动设计”为名按道理应该是领域逻辑越复杂的系统越需要“领域驱动设计”但领域驱动设计“大行其道”的地方却是“互联网系统”布道者很大比例来自“互联网公司”。常见的领域驱动设计文章是这样的先念经“DDD是解决业务系统复杂性的方法学”然后再把几个DDD造词吹一通这一套复制粘贴的常规操作做下来就已经占据不少篇幅了。接下来开始举例了但例子只有1-2个领域类涉及的领域逻辑也极其简单也许在DDD圈子看来已经够复杂然后就开始大谈实体、值对象、仓储、上下文、聚合根、六边形架构……还会给出代码代码一层又一层颇为壮观。一点点领域逻辑包出这么多饺子难怪伪创新买家开发人员会大喊“受用”也有银行、保险、医疗等行业组织中的开发人员分享“领域驱动设计”的心得你以为这回应该有真东西了吧仍然没有。他们象征性地简单罗列一些领域概念意思是“你看我这里有领域喔”然后还是前面那个套路最后声称领域驱动设计给他们带来了多少多少的好处。**********了解了这一点我们只需要问鼓吹的DDD Fans一个简单问题你现在真正在做的真实系统哪个地方领域逻辑最复杂具体是什么逻辑能清楚表达一下吗说一个地方就行了。形式不限口头、文本、流程图活动图、E-R图、类图、状态机图……都可以。然后像我在《DDD领域驱动设计批评文集》umlchina.com/url/ddd.html中那样用严谨的思维剖析他所给出的回答多半是漏洞百出。因为如果对方有这个能力大概率也就不会再去相信之前那些伪创新话术甚至会为曾经相信那些东西而羞愧。剖析过程中如有必要可以找我寻求“技术支持”。