根據我個人的領域建模經驗，總結了在領域建模過程中遇見的常見問題及對應的解決方案。

問題一

問題描述：業務專家與建模專家之間形成能力的“阻抗不匹配”。

就像對象和關系的“阻抗不匹配”一樣，業務專家精通業務，卻往往不具備建模能力，而建模專家又往往不熟悉業務（如我，只能泛泛地了解業務知識）。

這就是DDD為何強調領域專家與開發團隊工作在一起的主要原因。

解決方案：除了讓業務專家和建模專家共同工作，取長補短之外，還有一個辦法，就是向企業的業務專家開展領域建模的培訓，以提升他們的建模能力；同時，盡可能采用團隊成員共同參與的協作化可視化建模，以促進有效溝通，快速反饋，有效形成業務專家與建模專家的合力。

圖片

為何事件風暴得到大多數領域專家的認可，并成為一種主流的建模方法？其中一個原因就在于它通過可視化工作坊的形式，為業務專家和建模專家營造了良好的溝通氛圍和高效的溝通機制。所謂的“糊墻”游戲，使得參與者可以釋放自己，交頭接耳，大聲討論，清晰地表達各自的想法。大家協同建模，通過即時貼展現業務流程與事件流，一旦將它們掛在墻上，就很容易發現大家對業務問題理解不一致的地方，通過發現差異統一認識，也起到了傳播業務知識的目的。

可視化工作坊的形式可以有效杜絕“閉門造車”的專家建模，即便你不熟悉事件風暴，你也可以采用其他的頭腦風暴形式。

問題二

問題描述：在開展領域建模時，缺乏一套行之有效的方法與過程，導致“拍腦袋”建模和隨意建模成為常態，無法穩定地輸出高質量的領域模型。

解決方案：通過引入DDD方法，建立適合團隊的固化建模過程，是成功建模的必要條件。

下圖是我總結的服務風暴12步驟，要求團隊嚴格按照它規定的步驟逐步開展建模。

圖片

遵循我總計的領域驅動設計統一過程，共分為三個階段：

• 全局分析階段
• 架構映射階段
• 領域建模階段

每個階段都有4個步驟，并給出了每個步驟的執行過程與輸出結果。前一個步驟的輸出結果，又會成為后續步驟的重要輸入。

例如，我規定了全局分析階段的交付物包括業務流程圖、業務服務圖、業務服務規約和業務架構視圖。

圖片

圖片

圖片

圖片

架構映射階段的交付物包括系統上下文圖、限界上下文組件圖、API契約定義、服務調用時序圖和應用架構視圖。

圖片

圖片

圖片

圖片

圖片

領域建模階段的交付物包括限界上下文的代碼模型、靜態領域模型和動態領域模型。

圖片

圖片

圖片

問題三

問題描述：面對業務復雜度高，規模龐大的問題空間，難以保證建模的質量，也無法有效控制復雜度。

解決方案：需要遵循“分而治之”的思想，在各個層次開展抽象與分解的工作。

DDD提出的子領域可以有效分解問題空間，限界上下文和聚合在不同層次上完成對解空間的分解，都是建模的重要支點。下圖是我總結的DDD各層邊界控制的內容。

圖片

無論從問題空間到解空間，還是從戰略設計推進到戰術設計，領域驅動設計一直強調的核心思想，就是對邊界的界定與控制。

控制了模型（戰略層次和戰術層次）的邊界后，不僅因為縮小規模而降低了建模的復雜度，還能夠在規定好各個單元之間的協作機制后，將它們分配給不同的領域特性團隊，確定好職責邊界，開展并行建模，如此也可以極大提升建模的效率。

問題四

問題描述：容易出現大而全的領域模型，看起來很美，一旦落地，會發現得到的領域模型存在很大的問題。

解決方案：遵循“迭代建模”的原則。迭代的過程是兩個方向不斷迭代的過程。

一個方向是在更高層次上追求“廣度優先”，把建模工作盡可能覆蓋得更廣，形成統一而清晰的業務藍圖，包括主要的業務流程、劃分子領域、確定子領域與業務服務之間的關系，進而確定限界上下文、定義限界上下文外部的接口，明確限界上下文之間的協作關系。

另一個方向是選擇核心子領域追求“深度優先”，深入到這些核心子領域映射的限界上下文內部，編寫業務服務規約，迭代地開展領域分析建模和領域設計建模，甚至嘗試針對核心主流程對應的限界上下文開展實現建模，輸出功能不完整，但具有可用特性的可運行代碼。

融合廣度優先與深度優先的迭代建模方式，和DDD結合起來，簡單來說就是戰略設計采用廣度優先，戰術設計采用深度優先。

這種迭代建模方式需遵循MVP（Minimal Viable Product，最小可用產品）思想。在確定了解空間的限界上下文，可以開展如下圖所示的領域建模方式：

圖片

遵循MVP思想開展的迭代建模具有兩個優勢：

• 最小可用的領域模型：每次迭代獲得的領域模型都是可運行的，功能可驗證的，即在每次小步成功的基礎上開展增量式的迭代建模
• 分析設計實現的分離與統一：分析建模、設計建模和實現建模的主導者不同，目標不同，方法不同，卻又都是在前者基礎上開展的，從而保證了三個步驟的分離與統一，既降低了復雜度，又避免了模型的不一致

我特別害怕企業搞轟轟烈烈的“建模運動”，從上到下打雞血，定任務，高呼“奮戰30天，多快好省地打造企業級領域模型”，然后，集中核心成員加班加點完成一個貌似完整詳細、巨細無靡、規模龐大的超級領域模型，卻沒有產出哪怕一行可以工作的代碼。在得到這么一個超級領域模型之后，企業又召集許多業務專家和建模專家對它進行幾天封閉式的模型評審。這一做法雖然利用了團隊的力量，做了充分的溝通和協作，但和“閉門造車”的專家建模一樣，缺乏及時反饋與快速驗證，得到的大而全的領域模型很有可能只是一個看起來很美的空中樓閣。