領域場景分析的6W模型
在軟件構造過程中，我們必須正確地理解領域。一種生動的方式是通過“場景”來展現領域邏輯。領域專家或業務分析師從領域中提煉出“場景”，就好像是從抽象的三維球體中，切割出具體可見的一片。然后以這一片場景為舞臺，上演各種角色之間的悲歡離合。每個角色的行為皆在業務流程的指引下展開活動，并受到業務規則的約束。當我們在描述場景時，就好像在講故事，又好似在拍電影。
組成場景的要素常常被稱之為6W模型，即描寫場景的過程必須包含Who，What，Why，Where，When與hoW這六個要素。6W模型如下圖所示：
通過場景分析領域需求時，我們需要首先識別參與該場景的用戶角色。我們可以為其建立用戶畫像(Persona)，通過分析該用戶的特征與屬性辨別該角色在整個場景中參與的活動。這意味著我們需要明確業務功能(what)，思考這一功能給該角色能夠帶來什么樣的業務價值(why)。注意，這里所謂的“角色”是參差多態的，同一個用戶在不同場景可能是完全不同的角色。例如在電商系統中，倘若執行的是下訂單功能，則角色就是買家;針對該訂單發表評論，參與的角色就變成了評論者。
在6W模型中，我將領域功能劃分為三個層次，即業務價值、業務功能和業務實現，我將其稱之為“職責的層次”。定義為“職責(Responsibility)”，才能夠更好地體現它與角色之間的關系，即“角色履行了職責”。業務價值體現了職責存在的目的，即解釋了該領域需求的Why。只有提供了該職責，這個場景對于參與角色才是有價值的。為了滿足業務價值，我們可以進一步剖析為了實現該價值需要哪些支撐功能，這些業務功能對應6W模型中的What。進一步，我們對功能深入分析，就可以分析獲得具體的業務實現。業務實現關注于如何去實現該業務價值，因而對應于hoW。
在電商系統中購買商品時，對于買家而言，下訂單這一職責是具有業務價值的。通過領域分析，結合職責的層次概念，我們就可以得到如下的職責分層結構：
下訂單
- 驗證訂單是否有效
- 驗證訂單是否為空
- 驗證訂單信息是否完整
- 驗證訂單當前狀態是否處于“待提交”狀態
- 驗證訂單提交者是否為合法用戶
- 驗證商品庫存量是否大于等于訂單中的數量
基于業務規則計算訂單總價、優惠與配送費
- 獲取用戶信息
- 獲取當前促銷規則
- 計算訂單總價
- 計算訂單優惠
- 計算商品配送費
提交訂單
- 將訂單項插入到數據表中
- 將訂單插入到數據表中
- 更新訂單狀態為“待付款”
更新購物車
- 刪除購物車中對應的商品
發送通知
- 給買家發送電子郵件，通知訂單提交成功，等待付款
當我們獲得這樣的職責層次結構之后，就可以幫助我們更加細致地針對領域進行建模。在利用場景進行建模時，還要充分考慮場景的邊界，即6W模型中的Where。例如在“下訂單”的案例中，驗證商品庫存量的業務實現需要調用庫存提供的接口，而該功能實則屬于下訂單場景的邊界之外。領域驅動設計引入了限界上下文(Bounded Context)來解決這一問題。
針對問題域提煉領域知識是一個空泛的概念，業務場景分析的6W模型給出了具有指導意義的約束，要求我們提煉的領域知識必須具備模型的六個要素。這就好比兩位侃侃而談的交談者，因為有了確定的主題與話題邊界，一場本來是漫無目的野鶴閑云似的閑聊就變成了一次深度交流的專題高端對話。6W模型也是對領域邏輯的一種檢驗，如果提煉出來的領域邏輯缺乏部分要素，就有可能忽略一些重要的領域概念、規則與約束。這種缺失會對后續的領域建模直接產生影響。正本清源，按照領域場景分析的6W模型去分析領域邏輯，提煉領域知識，可以從一開始在一定程度上保證領域模型的完整性。
【本文為51CTO專欄作者“張逸”原創稿件，轉載請聯系原作者】
