当我做 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 中，对吧？

咱们甚至明确了咱们打算布局几个微服务，先做哪个后做哪个.”

…

最初我想说磨快刀子不耽搁砍柴， 事件风暴是一个简略而弱小的用来梳理业务需要和软件设计的工具.