下文源于我12月21日在TGO成都分會E家宴上的分享。我本人也是領域驅動設計的初學者，DDD（Domain-driven-design）是一種思考問題的方式和解決問題的方法，要想深入理解還需要反復的思考和練習。

正文：

今天我分享的主題是《領域驅動設計之事件風暴》。當我每次去思考把一個話題講清楚的時候，習慣于從Why（為什么），How（如何做），What（是什么）的角度展開。坦白地說，短時間甚至沒可能把領域驅動設計中的Why講清楚。所以構思今天這個分享的時候， 我反復斟酌，希望通過一條主線和大家一起走進領域驅動設計的世界。

我們還是從“為什么”開始：軟件系統設計面臨的挑戰。

我們都理解軟件開發的不確定性貫穿了整個軟件工程的生命周期，很多時候我們希望通過敏捷的方式來應對不確定性，在軟件工程里面這種不確定性包括進度、需求、成本等等。然而本就沒有所謂的“銀彈”：沒有一種單純的技術或管理上的進步，能夠獨立地承諾在10年內大幅度地提高軟件的生產率、可靠性和簡潔性。

那么如何應對業務的復雜性呢？在這個背景下，領域驅動設計橫空出世。

領域驅動設計是一種處理高度復雜領域的設計思想，試圖通過分離技術實現的復雜性，圍繞業務概念構建領域模型來控制業務的復雜性，以解決軟件難以理解、難以演化等問題。團隊應用它可以成功地開發復雜業務軟件系統，使系統在增大時仍然保持敏捷。

DDD有幾個核心思想：

1.軟件項目的主要聚焦點應該在領域和領域邏輯，不應該直接從需求開始設計數據庫表結構。

2.復雜的領域設計應該基于領域模型，領域模型是封裝了數據和行為的對象。

3.軟件工程核心實質是社會工程，優秀團隊的競爭力來源于互相的信任及良好的溝通。DDD強調技術專家和領域專家一起進行創造性的合作，從而可以不斷地切入問題域的核心。

領域驅動設計包括兩個階段：

以一種領域專家、設計人員、開發人員都能理解的通用語言作為相互交流的工具，在交流的過程中發現領域概念，然后將這些概念設計成一個領域模型；

由領域模型驅動軟件設計，用代碼來實現該領域模型。

Eric Evans在《領域驅動設計》中建議開發一個共享域模型，作為領域專家和IT之間的橋梁，它以無處不在的語言編寫并由應用程序代碼實現。近年來，為這些活動建立了兩種研討會的形式。

這兩種形式的研討會都有助于為IT專業人員提供對域的深入洞察和開發域的通用可視化模型。

下面我來以一個具體的電商場景為例，分享事件風暴工作坊是如何開展的。

事件風暴工作坊

準備工作

正確的人：領域專家，技術人員，用戶體驗設計師，測試人員等關鍵角色要參與其中。

開放空間：有足夠的空間可以將事件流可視化，讓團隊可以交互討論。

即時貼 & 筆：至少四種顏色，分別代表事件，命令，角色，聚合，外部系統，其他約束等。

事件風暴

設計業務場景：根據產品愿景與價值定位，設計關鍵場景，找出起點與終點。

找出領域事件

根據設計的業務場景，將領域事件寫在即時貼上。

每個即時貼表示一個事件。

事件采用“XX已XX”的格式，如“訂單已創建”。

事件排序

將自己的事件貼紙貼在白板紙上。

每個事件從左到右按時間順序排列。

不同事件需保證相對順序。

命令風暴

命令是產生事件的領域行為或領域活動，它可以是:

用戶的動作，比如提交客戶訂單。

外部系統觸發，比如啟動夜間對賬。

定時任務，比如鎖定賬戶。

找出命令

將命令寫在藍色即時貼上（關注用戶從UI界面進行的操作）。

將命令貼在所產生的事件旁邊。

識別出觸發命令的角色并進行標識（黃色即時貼）。

尋找聚合

找出領域名詞

通過分析前一步產生的領域事件尋找領域名詞，規則如下：

識別事件中有業務含義的名詞；

將含有相同名詞的事件合并；

確保名詞代表的業務概念清晰完整且沒有歧義；

用大黃色即時貼進行標記。

確定領域聚合

在確定領域聚合的時候，我們可以這樣思考：它是否可以被獨立訪問，如果可以被獨立訪問就是一個聚合，如果不能被獨立訪問就應該屬于它依賴的聚合。

最后留下聚合即時貼：命令在左面，事件在右面。

未完待續

在這個電商的場景中，如果我們聚焦于訂單的上下文，可以拆分出三個領域事件，分別是：訂單已創建、訂單已取消和訂單已支付。下一步我們要做的就是用代碼來實現該領域模型。

最后給大家推薦兩本非常經典的軟件管理學著作：《人月神話》和《人件》。這兩本書都不約而同地提到了軟件工程的核心思想：軟件工程核心實質是社會工程，優秀團隊的競爭力來源于互相的信任及良好的溝通。讓我們共勉，謝謝大家！

本文作者萬學凡，ThoughtWorks首席咨詢師，武漢。作者保留本文一切權利，未經許可請勿轉載。