如何運用 DDD 解決團隊協作與溝通問題？

點擊上方「程序人生」，選擇「置頂公眾號」

第一時間關注程序猿（媛）身邊的故事

領域驅動設計的核心是「領域」，因此要運用領域驅動設計，從一開始就要讓團隊走到正確的點上。當我們組建好了團隊之後，應該從哪里開始？不是UI原型設計，不是架構設計，不是設計數據庫，這些事情重要卻非最高優先級。

試想，項目已經啟動，團隊卻並不了解整個系統的目標和範圍，未對系統的領域需求達成共識，那麼項目開發的航向會否隨著時間推移而逐漸偏離？

用正確的方法做正確的事情，運用領域驅動設計，就是要先識別問題域，進而為團隊提煉達成共識的領域知識。要做到這一點，就離不開團隊各個角色的溝通與協作。客戶的需求不是從一開始就生長在那里，如同在茫茫森林中的一棵樹木，等待我們的眼睛去「發現」它。

相反，需求可能只是一粒種子，需要土壤、陽光與水分，在人們的精心呵護與培植下才能長成。因此，我們無法「發現」需求，而是要和客戶一起「培育」需求，並在這個培育過程中逐漸成熟。

達成共識

「培育」需求的過程需要雙向的溝通、反饋，更要達成對領域知識理解的共識。原始的需求是「哈姆雷特」，每個人心中都有一個「哈姆雷特」，如果沒有正確的溝通與交流方式，團隊達成的所謂「需求一致」不過是一種假象罷了。

由於每個人獲得的信息不同，知識背景不同，又因為角色不同導致設想的上下文也不相同，諸多的不同使得我們在對話交流中好似被蒙了雙眼的盲人，我們共同捕捉的需求就好似一頭大象，各自只獲得局部的知識，卻自以為掌控了全局。

或許有人會認為客戶提出的需求就應該是全部，我們只需理解客戶的需求，然後積極響應這些需求即可。傳統的開發合作模式，更妄圖以合同的形式約定需求知識，要求甲乙雙方在一份沉甸甸的需求規格說明書上簽字畫押，如此即可約定需求內容和邊界。

一旦發生超出該文檔邊界的變更，就需要將變更申請提交到需求變更委員會進行評審。這種方式從一開始就站不住腳，因為我們對客戶需求的理解，存在三個方向的偏差：

• 我們從客戶處了解到的需求，並非最終用戶的需求

• 若無有效的溝通方式，需求的理解偏差會導致結果大相徑庭

• 理解到的需求並沒有揭示完整的領域知識，導致領域建模與設計出現認知障礙

Jeff Patton在《用戶故事地圖》中給出了一幅漫畫，來描述共識達成的問題。我在 ThoughtWorks 給客戶開展 Inception 活動時，也使用了這幅漫畫：

這幅漫畫形象地表現了如何通過可視化的交流形式逐漸在多個角色之間達成共識的過程。正如前面所述，在團隊交流中，每個人都可能成為「盲人摸象的演員」。怎麼避免認知偏差？很簡單，就是要用可視化的方式表現出來，例如繪圖、使用便簽、編寫用戶故事或測試用例，都是重要的輔助手段。後面我會結合著領域場景分析來講解這些提煉領域知識的手段。

可視化形式的交流可以讓不同角色看到需求之間的差異。一旦明確了這些差異，就可以利用各自掌握的知識互補不足去掉有餘，最終得到大家都一致認可的需求，形成統一的認知模型。

團隊協作

在軟件開發的不同階段，團隊協作的方式與目標並不相同。在項目的先啟（Inception）階段，團隊成員對整個項目的需求完全一無所知，此時與客戶或領域專家的溝通，應主要專注於宏觀層面的領域知識，例如系統願景和目標、系統邊界與範圍、還有主要的需求功能與核心業務流程。在管理層面，還需要在先啟階段確定團隊與利益相關人（包括客戶與領域專家）的溝通方式。

先啟階段

在敏捷開發過程中，我們非常重視在項目之初開展的先啟階段，尤其是有客戶參與的先啟階段，是最好的了解領域知識的方法。如果團隊採用領域驅動設計，就可以在先啟階段運用戰略設計，建立初步的統一語言，在識別出主要的史詩級故事與主要用戶故事之後，進而識別出限界上下文，並建立系統的邏輯架構與物理架構。

在先啟階段，與提煉領域知識相關的活動如下圖所示：

上圖列出的七項活動存在明顯的先後順序。首先我們需要確定項目的利益相關人，並通過和這些利益相關人的溝通，確定系統的業務期望與願景。在期望與願景的核心目標指導下，團隊與客戶才可能就問題域達成共同理解。這時，我們需要確定項目的當前狀態與未來狀態，從而確定項目的業務範圍。之後，我們就可以對需求進行分解。在先啟階段，對需求的分析不宜過細，因此需求分解可以從史詩級（Epic）到主故事級（Master）進行逐層劃分，並最終在業務範圍內確定迭代開發需要的主故事列表。

迭代開發階段

在迭代開發階段，針對迭代生命周期和用戶故事生命周期可以開展不同形式的溝通與協作。在這個過程中，所有溝通協作的關鍵點如下圖所示：

迭代生命周期是針對迭代目標與範圍進行需求分析與溝通的過程。團隊首先要了解本次迭代的目標，對迭代中的每個任務要建立基本的領域知識理解。在迭代開發過程中，我們可以借鑒 Scrum 敏捷管理過程。

Scrum 要求團隊在迭代開始之前召開計劃會議，由產品負責人（Product Owner）在會議中向團隊成員介紹和解釋該迭代需要完成的用戶故事，包括用戶故事的業務邏輯與驗收標準。團隊成員對用戶故事有任何不解或困惑，都可以通過這個會議進行溝通，初步達成領域知識的共識。每天的站立會議要求產品負責人參與，這就使得開發過程中可能出現的需求理解問題能夠及時得到解答。Scrum Master 則通過每天的站立會議了解當前的迭代進度，並與產品負責人一起基於當前進度和迭代目標確定是否需要調整需求的優先級。

迭代結束後，團隊需要召開迭代演示會議。除了開發團隊之外，該會議還可以邀請客戶、最終用戶以及領域專家參與，由團隊的測試人員演示當前迭代已經完成的功能。

這種產品演示的方法更容易消除用戶、客戶、領域專家、產品負責人與團隊在需求溝通與理解上的偏差。由於迭代周期往往較短，即使發現了因為需求理解不一致導致的功能做到偏差，也能夠做到及時糾偏，從而能夠將需求問題扼殺於搖籃之中。

每一個功能的做到，每一行代碼的編寫都是圍繞著用戶故事開展的，它是構成領域知識的最基本單元。用戶故事指導著開發人員的開發、測試人員的測試，其質量會直接影響領域驅動設計的質量。

敏捷方法非常重視發生在用戶故事生命周期中的各個關鍵節點。對於用戶故事的編寫，敏捷開發實踐強調業務分析人員與測試人員共同編寫驗收測試的自動化測試腳本，這在《實例化需求》一書中被稱之為「活文檔（Living Document）」。測試人員與需求分析人員的合作，可以為需求分析提供更多觀察視角，尤其是異常場景的識別與驗收標準的確認。

當用戶故事從需求分析人員傳遞給開發人員時，不管這個用戶故事的描述是多麼的準確和詳細，都有可能導致知識流失。因此，在開發人員領取了用戶故事，並充分理解了用戶故事描述的需求後，不要急匆匆地就開始編碼做到，而是建議將需求分析人員與測試人員叫過來，大家一起做一個極短時間的溝通與確認。

我們稱這一活動為「kick off」。這種方式實際就是對「盲人摸象」問題的一種應對。在這個溝通過程中，開發人員應盡可能多問需求分析人員「為什麼」，以探索用戶故事帶來的價值。

只有如此，開發人員才能更好地理解業務邏輯與業務規則。同時，開發人員還要與測試人員再三確認驗收標準，形成一種事實上的需求規約。

當開發完成後，是否就意味著我們可以將做到的故事卡，移交給測試呢？雖然通過迭代開發以及建立特性團隊，已經大大地拉近了開發人員與測試人員的距離，縮短了需求從開發到測試的周期。

但我們認為，有價值的溝通與交流，怎麼強調都不過分！磨刀不誤砍柴工。我們認為從開發完成到測試開始，也是一個關鍵節點，建議在這個關鍵節點再進行一次交流活動，即在開發環境下，由開發人員向需求分析人員，與測試人員「實地」演示剛剛完成的功能，並對照著驗收標準進行驗收。我們稱這個過程為「desk check」，是一個快速迷你的功能演示，目的是快速反饋，也減少了任務卡在開發與測試之間頻繁切換的溝通成本。

通過desk check的用戶故事卡才會被移動到「待測試」。不必等到迭代結束，更不必等到版本發布，只要開發人員完成了用戶故事，測試人員就應該在迭代周期內進行測試。

未經過測試的用戶故事其交付價值為0，可以認為這張用戶故事卡沒有完成。這也是大多數敏捷實踐對所謂「完成（Done）」的定義。

無數研究與實踐也證明了，修改 Bug 的成本會隨著時間的推移而增加，如果在開發完成後即刻對其進行測試，一旦發現了 Bug，開發人員就能夠快速響應，降低修改 Bug 的成本。當然，測試的過程同樣是溝通與交流的過程，是最有效的需求驗證和質量保障手段。

敏捷思想強調個體和團隊的協作與溝通，強調快速反饋與及時響應。前面探討的這些敏捷實踐都是行之有效的溝通機制和交流手段，可以幫助團隊對需求的理解更加全面更加準確。

只有頻繁地溝通，才能就業務需求達成整個團隊的共識；只有良好的協作，才能有助於大家一起提煉領域知識，建立統一語言；只有快速反饋，才能盡可能保證領域模型，與程序做到的一致。這些都是實踐領域驅動設計的基本前提。

以上文章節選自我在 GitChat 平台獨家發布的 DDD 系列精品課上篇：《領域驅動戰略設計實踐》，本課程限時特價39元，共計34篇，形式為「圖文+音頻」；特價時間為即日起到 7月30日 。訂購本課程還可在 GitChat 讀者圈與我交流互動，歡迎所有熱愛 DDD 的朋友一起交流學習！

掃描下方二維碼了解本課程

專家推薦

張逸不但擁有過硬的領域驅動設計實踐經驗，而且是一位能夠深入淺出的闡釋者。這兩項特質保證大家能夠收獲滿滿！

——ThoughtWorks 咨詢總監、精益敏捷專家，肖然

我做了多年大規模微服務架構，也見了許多微服務實施案例，其中做得好的無一例外對領域模型有了深入的分析，做得不好的往往只關注工具和框架而忽略了領域模型。張逸是國內 DDD 領域少有的專家，我向大家推薦他的《領域驅動設計實踐》系列課程。

——阿里巴巴高級技術專家，許曉斌

國內同仁寫的軟件需求設計方面的圖書，我都有收集，但能認真閱讀的不多。張逸寫的書是少數我認真閱讀過的，推薦給大家。

——UMLChina 首席專家，潘加宇

作者簡介：張逸，曾先後就職於中興通訊、惠普 GDCC、中軟國際、ThoughtWorks 等大型中外企業，任職角色為高級軟件工程師、架構師、技術總監、首席咨詢師。GitChat 暢銷精品課作者。

精通包括 Java、Scala、Python、C#、JavaScript、Ruby 等多種語言，熟練掌握面向對象思想、測試驅動開發與重構、領域驅動設計、函數式編程、架構、大數據分析、敏捷與過程改進，並致力於大型軟件企業的面向服務系統架構設計、大數據平台架構設計以及互聯網 Web 系統架構設計。

著譯作包括《軟件設計精要與模式》、《Java 設計模式》、《恰如其分的軟件架構》、《WCF 服務編程》、《人件》、《重構——改善既有代碼設計》評註版、以及《架構之美（Beatiful Architecture）》評註版。

版權聲明：本文及文中所涉及課程均為 GitChat 平台獨家發布，未經授權不得轉載。

點擊「閱讀原文」，也可秒進課程頁面！

———- 我是神奇的分割線 ———-

今晚8點30分，進群免費聽安曉輝的線上分享

掃描下方海報二維碼，添加小助手，回復「分享」，小助手會邀你進群。免費聽《工程師的成長課》該書作者安曉輝的分享。

同時，作者還會在群里和大家交流互動，為你個人在未來職業規劃上的問題和困惑指明方向。

分享結束後，會在群內抽出3名互動積極用戶，免費送出作者著作一本！