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