記一次事件工作坊的經歷。

當你回顧你的經歷時，你正在理解和消化你的初衷。

項目上一次偶然的機會，接觸到了領域驅動設計。一開始接觸新的概念時，總感覺它高深莫測，不知道如何運用。后來才明白，當你想要解決問題而使用這個工具時，你就開始了對他理解的過程。

這次工作坊中其實我主要扮演的是一個領域專家和觀察者的身份。工作坊的過程主要分成了三個部分，電梯演講，事件風暴和領域模型劃分。下面我將嘗試通過我對這三個部分的體驗感受來描述我對于領域驅動設計的理解。

電梯演講

為了目標群體，他們的訴求或痛點，這個產品名稱，是一個產品特征，它可以不可抗拒的優(yōu)點，而不像其他競品，我們的產品核心的差異化競爭力。

這是業(yè)務的第一次發(fā)散。當一個領域專家在講一個業(yè)務愿景的時候，是非常發(fā)散的。他會開始介紹他對于業(yè)務的各種理解和暢想，以及他期望達到的一個長遠目標。而電梯演講的目的就是對一個復雜的發(fā)散業(yè)務做第一次的聚合。它的目標是把一個龐大而又模糊的業(yè)務目標，抽象成一個直觀的產品目標。然后將項目成員的注意力集中在某一領域，而該領域也將成為你產品所要滿足的業(yè)務核心領域。

因此，在一個復雜的業(yè)務體系中，解構出我們優(yōu)先需要解決的痛點和問題，這是關鍵的第一步。

很多時候，業(yè)務分析師在跟客戶聊了很久后，發(fā)現他依然難以邁出第一步。這背后的原因就是他沒有能夠很好的將客戶發(fā)散的思維聚合成一個可達到的明確目標?？蛻舻南敕ㄊ欠浅；钴S，發(fā)散和無序的，當他在描述業(yè)務時，需要的是我們快速理解和抽象思維的能力，從而在一個自然語言的業(yè)務描述中迅速解構出的核心訴求和痛點，并以此基礎出發(fā)，歸納產品的核心目標。這也就是我們常說的MVP（Minimum Viable Product）。我們的產品不能解決他的所有問題，但一定會解決他現實業(yè)務的核心問題。而什么是業(yè)務核心，其實是一個服務商需要去幫助領域專家去判斷和分析的。

這個流程的目的就是為了快速的統(tǒng)一大家的目標和愿景，能夠在接下來的發(fā)散中很好的去限定自己的業(yè)務范圍，以便將產品目標拆解成事件。

事件風暴

使?事件?風暴梳理業(yè)務流程，建?領域模型，劃分邊界。領域事件一定是能夠解決業(yè)務痛點，體現產品目標和價值的事件。

當大家構建好一個統(tǒng)一的產品愿景和目標時，接下來就是識別實現目標過程中所發(fā)生的事件了。這時候很多人會認為，在統(tǒng)一的產品目標下（即使是非常直觀的業(yè)務描述），項目成員會天然的以統(tǒng)一的業(yè)務概念去理解產品目標所包含的事件。這是一個誤區(qū)。事件風暴的其中一個目的就是在產品目標的范圍內，廣泛的讓團隊成員發(fā)散的識別業(yè)務事件，然后通過和領域專家的反復確認，來確保成員對產品目標和業(yè)務事件的理解在同一個層面上。這個過程中，非常忌諱兩件事：

1. 在識別事件前就對事件做了預判；2. 識別出的事件不能映射開始設定的產品目標。

第一件事造成的后果是，在成員還沒分解出業(yè)務事件前，就對什么是事件做了限定和規(guī)范。這很容易讓大家失去了再一次對業(yè)務概念統(tǒng)一語言的機會。成員對業(yè)務事件不斷的拆解和發(fā)散，才能再次檢驗成員是否對業(yè)務概念的理解在同一層面上。

第二件事造成的后果是，在原本已經聚合的領域中，再次發(fā)散出更多的領域。這不僅推翻了電梯演講的結果，同時也會把項目成員再次拉回到業(yè)務領域的定位上。一方面會花費太多時間識別不在產品目標內的事件，另一方面也會影響大家對產品目標的理解和領域專家的判斷。事件風暴中，避免再次引入與產品目標無關的上下文，可以很好的將成員限定在一個高效，直觀，清晰的愿景中，并以此愿景對事件進行有效梳理。

發(fā)散是事件風暴的開始，但絕不是事件風暴的目標。真正的目標是在有限的時間內，聚合出領域事件。那么什么是領域事件？這時候請回歸到產品定位。問問自己，這個事件的發(fā)生是否解決了業(yè)務痛點，是否會催生業(yè)務價值的產生。此時，你也可以和領域專家在一個可視化（將你識別的事件寫成Sticker）的基礎上對業(yè)務事件再次確認，幫助你判斷。有時候，如果正向詢問無法判斷時，不妨反問自己，這個事件不發(fā)生會有什么影響，不發(fā)生是不是就達不成產品目標？這樣也能有效地識別出領域事件。

領域模型劃分

通過分析前一步產品的領域事件尋找領域模型。

當我們識別出領域事件后，我們應該做什么呢？這時不妨想想你的初衷，我們?yōu)槭裁匆鲱I域驅動設計？業(yè)務的變化和發(fā)展是不可預測和控制的，在原本的系統(tǒng)設計中，我們習慣通過業(yè)務流程和用戶操作來建立實體間的聯系，這種設計方式很便捷也很直觀?？僧敇I(yè)務發(fā)生變化時，當你再用之前的系統(tǒng)結構去解決業(yè)務問題時，你會發(fā)現你需要構建一個更復雜的實體或邏輯來實現業(yè)務變化。這時候你首先要做的，就是解耦系統(tǒng)架構和數據實體的依賴關系。當你成功解耦依賴，你會發(fā)現你一個復雜的業(yè)務系統(tǒng)可以通過領域模型的聯系來解釋，因此領域模型的提煉是為了實現架構設計上的解耦。

當分析清楚領域事件，命令和用戶后，你可以方便的提煉領域事件中同類的事件實體，并歸納出該實體上可能發(fā)生的命令。這些命令將會指導你設計對該實體的系統(tǒng)操作。在這樣的劃分中，能夠有效的識別出一個事件實體，在完成你的業(yè)務目標過程中，會通過什么樣的命令，經歷什么樣的事件變化。這種領域模型的劃分，很好的對實體對象進行了一次提煉。

聚合通過定義對象之間清晰的所屬關系和邊界來實現領域模型的內聚，避免錯綜復雜的對象關系?的形成，確保業(yè)務規(guī)則在領域對象的各個生命周期都得以執(zhí)?。

經過這次工作坊的實踐后，讓我們再次回到領域事件的三原則：

P1: 聚焦核?領域（保證團隊成員始終在一個統(tǒng)一的產品愿景下，通過識別領域事件，劃分出體現業(yè)務價值的領域模型）

P2: 通過協(xié)作迭代式探索模型（每一次的發(fā)散和聚合都是通過探索，逐步將一個復雜業(yè)務系統(tǒng)進行歸納，抽象和解耦。這個過程并非一蹴而就，而是需要反復討論和溝通的。同時記住沒有一個系統(tǒng)能解決所有問題，請始終關注在現有業(yè)務的核心領域事件上）

P3: 統(tǒng)?語言（將業(yè)務概念可視化是最好的統(tǒng)一語言的方式。當成員不在一個語言環(huán)境下時，團隊將無法進行有效的信息碰撞，導致業(yè)務事件識別的偏差。因此構建直觀，清晰和統(tǒng)一的語言環(huán)境是劃分領域模型的基礎）

總的來說，這是一次良好的體驗，作為一個領域專家和觀察者，能看到成員在不斷的試錯過程中強化對于領域驅動設計概念的理解。當然，一個方法論從消化到實施需要一個漫長的過程，但正如我文中一開始說的，請首先邁出你的第一步。