当我做DDD企业培训时候问: “谁知道领域驱动设计”，只有不到10%的人会点头。
当我问谁经历过Deadline驱动的开发，几乎所有人都会心领神会。
本末倒置的DDD
下面我分享一下在企业里面DDD落地的一个故事
T先生是我赋能DDD的一个BA，我们先是在Lab1中用DDD的方法论做了一个MVP项目。然后一个星期之后再进行另一个Lab2 MVP的开发设计，我们又见面了，事先约定由T先生梳理好需求”
一个星期后， 我们站在下面这张用户故事地图前，T满脸愁容：
无事件风暴的用户情景图
我说：“这是你整理出来的用户故事是吗？事件风暴做了吗?”
T调整了一下站姿，侧身小声对我说：“我感觉在Lab1当中事件风暴的输出好像就是用户故事。那么我现在直接就把用户故事整理出来，这样会快一点。”
当时出现了几秒钟禁止画面。我然后说：“我明白了， 我们虽然是通过用户故事对接上迭代的开始，但是事件风暴的意义不仅仅是产生用户故事。另外你怎么分析的用户故事，你怎么确定分析准确不准确?”
接下来，我又开始讲了一些事件风暴的价值。
“首先，最重要的一点是要让开发者参与进来，要互动起来。事件风暴本省是一个让领域专业知识和开发人员信息沟通的桥梁和平台。有了这样一个高效，可视化的平台，业务知识才可以从领域专家的头脑中流到开发人员的头脑中，再通过开发人员的双手敲进计算机里面。”
“其次，我们需要确定系统的不同领域级别，从战略上定位出来你要构建的系统的核心域，支撑域，和通用域, 不同域采用的策略，投入的精力，和优先级是不同的。“
“你还需要分析出都有哪些聚合，聚合根，这些才是我们系统的心智球，没有这些，系统是不清晰也很难贴合实际的业务流程和场景的。”
看到T脸上神秘的笑容，他说：“好吧，我同意，不过Z总的意思希望我们尽快开始迭代”。（Z总是我们的PO，产品经理）
然后找到Z总，再复读一遍。我最后又加了几句助攻:”我很理解我们8月底有上线压力。然而磨刀不误砍柴功。事件风暴就设计用来进行快速业务流程分析的工具。”
下面是经过一天由BA，开发人员还有教练共同参与完成的部分业务流程的事件风暴样子。
事件风暴地图的一部分
站在这墙前，从表情来看，T如释重负。
我问“做完事件风暴前后的用户故事，你觉得有什么不同？”
T说：“有不同，我们发现了一些之前没有考虑到的用户故事和细节。比如：合同正文附件聚合，当我一开始试图再头脑中理清的所有场景时，这一点被忽略了。”
我说：“那你知道为什么当时会错过这些细节吗?”
T说：“当我思考这些需求的时候，想抓住所有的用户故事时，我仿佛只见森林，不见树木。很多细节都无法识别。但是，当我们开始事件风暴时，我觉得就像是踏进森林的一条条小路，穿过它，很多业务中的流程和信息开始变得清晰了。”
我说：“是的，事件风暴帮助你把头脑中的业务流程和场景扩展到这些物理墙上，让每个人都能看到它们。它不仅可以帮助你认清业务流程和细节，更重要的是可以帮助所有开发人员查看,了解所有细节，从而尽可能地掌握整个流程的心智模型。 如果没有这些认知，那么我们的开发人员就无法根据正确的业务理解开发功能而是基于一些误解。”
T补充说：”我觉得事件风暴特别有用，它解决了我一开始的一些困惑，我知道现在是什么困扰着我，然后我很清楚可以问最终用户一些什么问题。”
我说：“你也回答了很多来自开发团队的问题，对吧？如果他们没有看到所有的细节,参与其中，他们无法问出这些问题，因为信息极其不对称，程序员他们的关注点，和知识范畴和业务专家有很大的不同。这些知识他们不提前问你就会在sprint后期问你。因为他们一定在开发用户故事的时候卡住，你会看到Scrum看板中，看到进行中的任务会大量堆积，就像草裙一样。 这是一个反模式，就是进行中的任务过多。 你现在知道为什么了吗？”
T笑了，他似乎对我描述的情景相当熟悉。
“现在我们也知道应该分多少个域，我们应该在sprint 1中优先处理哪个域，而不是将很多分散的用户故事放在一个sprint中，对吧？
我们甚至明确了我们打算规划几个微服务，先做哪个后做哪个.”
…
最后我想说磨快刀子不耽误砍柴，事件风暴是一个简单而强大的用来梳理业务需求和软件设计的工具.
