當我做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中，對吧？

我們甚至明確了我們打算規劃幾個微服務，先做哪個後做哪個.”

…

最後我想説磨快刀子不耽誤砍柴，事件風暴是一個簡單而強大的用來梳理業務需求和軟件設計的工具.