提煉DDD的首要原則第二節——《領域驅動設計15年》
4. 原則1：就問題達成一致意見
「如果不能直面核心問題，就別指望有明顯改善。」——Eli Goldratt
想要知道應該在哪裡集中發力，首先要搞清楚待解決問題背後的動機。只有對業務全局有充分的瞭解，才能理解上下文中的問題。要問自己，是哪些問題、約束和機會讓我們走到了今天，這個問題值得擁有一個解決方案？
為什麼要這麼問？因為要保證充分理解待解決的問題。如果沒有這些基本信息，就很難保證說能夠提出一個卓有成效的解決方案。這裡要透露一個祕密——業務夥伴也沒有全部的答案。如同你是技術領域的專家一樣，他們也是各自領域的專家。但他們並不是設計系統或流程的專家。他們自己所做的事情，只是基於假設罷了。所以，不要流於表面，而是要和他們協作併產生共情。這樣纔可以觀察到業務夥伴的思考過程，瞭解他們是如何得出的結論。這些活動能讓技術團隊著眼於更簡單的替代解決方案，或者找出遺漏掉的供應鏈或流程鏈上游的問題，增加真正的業務價值。影響地圖(Impact Mapping)這樣的技術，非常適合把這些活動突顯出來。
多問為什麼總是值得的，不要全盤接受其他人的觀點，哪怕他們拍著胸脯信誓旦旦地保證，這就是上游業務所需的正確的解決方案，而並不是局部優化或未來願望。要問自己，如何構建能讓業務與眾不同的應用程序？如何匹配公司的戰略？為什麼要著眼於技術解決方案？一部分軟體是否就能為業務創造競爭優勢？系統性地追問「為什麼」，最終往往會揭示兩種結果，要麼是異常簡單的解決方案，要麼是業務方向的180度大轉彎。顯然，不要像孩子在課堂裏那樣提問，而應該充滿想像力地探究真相，牢牢地抓住問題，順藤摸瓜直到找到問題的根源。
當然，這並不是期望你成為代理首席執行官，引領公司轉變業務方向。但是至少應該在更加深刻的層次上，質疑並理解人們解決問題的動機。這將使你和團隊認可眼前的想法，並全身心地投入其中。
4.1. 明確如何交付業務價值
「人們其實不想買四分之一英寸的鑽頭，他們只想要四分之一英寸的洞！」 —— Theodore Levitt[7]
軟體開發人員在很大程度上，是解決問題的人。他們的工作是為業務創造價值並掃除阻礙，而不是編寫代碼。代碼應該被視為尋找業務問題解決方案這個過程的副產品。也就是說，有時開發人員無需技術方案就能夠解決問題。開發人員應當注重對業務成效的貢獻，而不是軟體產出。我們的目標並不是要寫出優雅的代碼，而是為了獲得有利於業務的結果。
IT部門也是業務的一部分。所以不應滿足於基於開發人員對業務的理解來創造軟體，而應致力於創建有助於實現整體業務目標的解決方案。這是一個微妙卻很重要的區別。就好比「我堵在車流裏了」這樣矛盾的說法——你的車沒有堵在車流裏，你的車就是車流的一部分。軟體開發人員就是業務的一部分，只不過他們剛好是軟體設計領域的專家，就像會計師是金融領域的專家一樣。不應該有他們和我們這樣涇渭分明的思想。
前面已經提到，對大多數業務來說，IT比以往任何時候都更具戰略意義。想想柯達和百視達這些已經消失的商業巨頭，科技進步已經顛覆了許多市場。站在業務領域的角度來採取行動，去交付真正的價值；藉助技術領域的知識來識別商機，去幫助業務夥伴理解讓步的藝術。追求經濟利益，思考如何促進KPI的轉移，如何在消除業務瓶頸的過程中發揮作用？這纔是成功的方式，這纔是實現真正價值的方式。
4.2. 揭示商業價值所在的技術
有關聚焦來實現業務價值的技術，真是不勝枚舉。例如
- 商業模式畫布（The Business Model Canvas）
- 精益企業創新組合（The Lean Enterprise Innovation Portfolio）
- Wardley 地圖（Wadley Mapping）
- 用戶旅程地圖（Customer Journey Mapping）
- 領域故事會（Domain Storytelling）
下面將詳細說明其中4種方法，這些都十分強大，特別有用。
4.2.1. 事件風暴
事件風暴這項工作坊活動，充滿樂趣和參與感。其目的是幫助業務人員和開發團隊，快速建立對問題域的理解。帶著問題的開發團隊成員，與帶著答案的領域專家，一起協作建立對問題域的共同理解。
這種知識消化活動，需要一個開放的環境，這樣纔有充足的空間進行可視化建模。可以使用許多白板作為建模畫布，也可以使用一長卷的牛皮紙。問題域的探索從領域事件開始。領域事件就是發生在業務關心的問題域內的事件。首先把代表領域事件的便利貼粘到畫布上，然後將注意力轉到事件的觸發者上。事件可能是由用戶操作引起的，這些用戶操作就應該作為命令被捕獲並貼到畫布上。外部系統或其他事件也可能是事件的起源，它們也會被貼到畫布上。探索活動會一直持續下去，直到所有問題都得到了解答。然後，團隊可以開始建立模型，這些模型會圍繞事件的決策點，及這些事件所產生的新事件。
就培育統一語言來說，事件風暴是一項非常有用的活動。因為每個事件和命令都有明確的命名，所以非常有助於在開發人員和業務專家之間達成共識。然而這類活動最大的優點，是十分有趣，引人入勝，而且可以快速完成。Alberto Brandolini發明瞭這類活動，可以在eventstorming.com找到更多信息。
4.2.2. 影響地圖
影響地圖是一項可以更好地瞭解開發人員如何影響業務成效的技術。影響地圖所帶來的產出，要遠超傳統的需求文檔。其中要做的，是設法搞清楚業務想要產生的影響是什麼。業務的目標是增加銷量？還是增加市場份額？還是要進入一個新市場？也許業務希望提高參與度來培育更多忠實客戶，這些客戶具有更高的終生價值。
一旦理解了業務想要產生的影響，就可以在幫助他們達成目標時，發揮更有效的作用。尤其是對DDD而言，如果知道了業務希望達成的目標，就可以在「知識消化」的討論中提出更恰當的問題。然而令人驚訝的是，影響地圖並不是一種鄭重其事且充滿儀式感的技術。只需創建一些可以突出關鍵業務信息的圖表就夠了，比如思維導圖。此時要與業務人員一起合作，完成「知識消化」，來助力建立產品共同願景。
顧名思義，影響地圖是從影響開始的。例如「自行車銷量增加25%」。與影響直接相連的節點是角色——能夠為實現所期望的影響做出貢獻的人。圖中的例子裏，開發人員和數據科學家就是這些角色。角色的子節點是他們能夠做出貢獻的方式。改善網站性能讓人們更樂於購物，這是開發人員幫助產生業務影響的一種方式。最後，層次結構的最後一級展示了可以實現的實際任務。在圖中，可以看到開發人員讓網站變得更快的一種做法，是移除緩慢的框架。
在許多軟體項目中，開發人員只能身處影響地圖靠後的層級。需要開發人員做什麼，以及如何實現，這些都需要業務人員來決定。但是，通過影響地圖，就可以把業務人員的設想層層展開，找出業務真正想要實現的目標。然後，開發人員就可以發揮自己的技術專長，提出業務人員想都沒想過的更勝一籌的替代方案。
無論是和DDD搭配運用，還是單獨運用，影響地圖都獲得了一些DDD實踐者的高度評價。我們強烈建議瀏覽影響地圖網站或獲取Gojko Adzic所著的《影響地圖》一書來深入地學習這項技術。
4.2.3. 理解商業模式
商業模式包含大量有用的領域信息，並能將業務的基本目標突顯出來。可惜的是，大部分開發人員根本不會花時間去了解僱主的商業模式，甚至連商業模式究竟是什麼都不想了解。
運用商業模式畫布，將公司的商業模式可視化，是瞭解公司商業模式的最佳方法。這項可視化技術由Alexander Osterwalder和Yves Pigneur在其影響深遠的著作《商業模式新生代》中提出。我們強烈推薦開發人員掌握這項技術，而且商業模式畫布對開發人員來說也非常容易理解。商業模式畫布非常有用，它將商業模式分解成了一個九宮格，如下圖所示。這幅圖展示了一個線上運動裝備供應商的商業模式。
對商業模式九宮格的理解，有助於搞清對於一家企業而言什麼纔是重要的。其中的關鍵信息包括：公司如何賺錢，最重要的資產是什麼，以及最重要的目標客戶有哪些。商業模式中的各個部分介紹如下。想要了解更多的信息，《商業模式新生代》一書是絕佳的學習資源。
- 客戶細分：企業面向的不同類型的客戶，例如利基市場、大眾市場和企業對企業（B2B）
- 價值主張：企業為其客戶提供的產品或服務，例如實體商品和雲服務託管
- 渠道：企業如何向客戶提供產品或服務，例如實體配送和網站
- 客戶關係：業務與每個客戶細分市場的關係類型，如直接的個人助理和自動的電子輔助設備
- 收入來源：企業獲得現金收入的不同方式，例如廣告收入和定期訂閱收費
- 核心資源：企業最重要的資產，例如知識產權和重要員工
- 核心活動：確保商業模式可行的基本活動，例如軟體開發和數據分析
- 重要合夥夥伴：企業最重要的合作夥伴名單，例如供應商和顧問
- 成本結構：企業產生的成本，例如薪酬、軟體訂閱和庫存
在商業模式畫布所提供的信息的幫助下，就有能力向領域專家提出有意義的問題，並幫助推動業務的發展，而不是把自己侷限在技術實施上。在尋找並理解僱主商業模式上的投入很小，事半功倍，十分值得。
4.2.4. 運用約束理論和系統性思考
約束理論（The Theory Of Constraints, TOC）是Eli Goldratt提出的一套管理哲學。他指出妨礙系統達成目標的，是一些不起眼的小約束。因此，應當專註並致力於消除系統的這些約束，這比其它任何事情都重要。這將確保任何努力的產出，最終都能為業務目標帶來最大化的成效——通常就是獲得收入。簡單來說，就是找出限制業務創造價值的那些瓶頸，然後加以消除。
約束理論的流程有5步：
- 找出約束：瞭解造成瓶頸或妨礙業務產生價值的關鍵問題
- 確定消除約束的辦法：集中全部力量儘快消除約束
- 讓其它事情服從約束：不要在與約束無關的任何其他問題上分心。其他的任何努力，都是浪費精力。解決約束的優先順序最高
- 消除約束：將解決方案應用於約束，來消除約束
- 確定約束已經消除：有時問題可能被推到了上游或者下游。如果是這樣，只需重複上面4個步驟，來處理新的約束
約束理論認為，在思考層面上，宏觀要勝於微觀。要優化的，不是某個環節，而是完整的鏈條或整個系統。換句話說，目的是優化業務達成整體目標，而不是優化整體服務的某個子部門。
但這與DDD有什麼關係？DDD理念的核心，就是領域或業務。其設計決策，應該是要驅動業務價值的。如果不瞭解阻止業務創造價值的約束，那麼就無法做出在何處重點發力的正確決策。約束可能是核心域，也可能是支撐域中影響核心域的的問題。改善約束之外的任何問題，可能都有其價值，但那不是最有價值的事情。這意味著要在思想上打破涇渭分明的筒倉，確保團隊的大局觀，讓團隊可以在最合適的發力點上，全力以赴。
例如，假設某個團隊的任務是將在線交易量提升10個百分點，而你就是團隊的一員。此時可以運用約束理論來確定用戶結賬付款時的約束是什麼，來對齊應該聚焦的發力點。是註冊頁面的問題嗎？如果發現大量的付款在中途退出，就可以尋找解決方案並糾正這個問題。接下來，就是找出影響結賬付款的下一個大的約束。結賬流程也許沒什麼問題，但事實上通過增加產品種類，就可以實現10％的交易增長，這樣做同樣可以達到目的。但如果約束並不在這個環節，而是在流程的上游，那麼即使竭盡所能，費勁心思，產生的影響也微乎其微。
5. 原則2：通過協作尋求解決方案
如果能對齊真實的業務約束或機會，那就能從雖很好地把握需求，但只能淺顯理解問題域，提升到能深入理解業務需求，並關注可以抓住的機會。請記住，人們會說他們想要什麼，但不會告訴你什麼是好的產品。這兩者之間的差異是微妙的，但會導致非常不同的結果。因此，不要坐等需求，而是去提供解決方案吧。
首先要以全局視角出發，理解解決方案的願景，以便每個人都能對齊目標。然後，凸顯其中重要的領域，並標識那些次要的領域。組織一些模型設計和問題簡化的工作坊，讓業務和技術人員在其中進行協作。需要積極參與那些遠離電腦的解決方案設計活動，在其中貢獻自己對需求的理解，而不是把此事交給他人。
我常想，一個角色的名稱能否名副其實？當投身IT行業時，我的第一個職位是分析師程序員。分析師指對主題進行分析的人，而程序員則指編寫計算機程序的人。因此，我的一半工作是理解問題，另一半則是將這些理解轉化為計算機可以懂的語言。而諸如軟體開發者和軟體工程師之類的職位，則應只關注技術方面，並假設解決方案已經足夠細化，可以轉化為一組需求。然而我們都知道，現實很少如此。
只關注技術會帶來一個更大的問題：當為具有複雜邏輯的系統設計軟體時，敲代碼本身永遠不會成為瓶頸。代碼是以下過程的產出物——開發人員和領域專家共同工作，並為問題域的解決方案創建模型。所以代碼表示協作和探索過程的結束。開發人員的工作就是解決問題。而離開電腦與域專家合作，有時可以更輕鬆地解決問題。最終，在學習和理解領域之後，就產出了可以工作的代碼。
5.1. 表現出對問題領域的激情
「無知是生產力的最大障礙。」 —— Dan North
開發人員非常善於在技術和項目方法方面進行自我教育。然而，分解問題並能夠從不重要的東西中提煉出重要的來，這種能力會使開發人員從優秀走向偉大。所以要確保花在理解問題空間的時間，與花在理解解決方案空間的時間一樣多。
就像一個有用的模型是通過一系列迭代得出的一樣，問題空間也必須被細化，以揭示原始願景背後的真實意圖。就如同操練如何編程，開發人員也應該操練如何傾聽和描繪利益相關者所關心的意圖、內容和時間點。
軟體開發是一個學習的過程，以求在問題領域中發現深刻的洞見。軟體開發是理解業務的過程。若軟體能解決業務問題，那麼就說明對業務的理解是正確的。好奇心和對理解問題空間的真誠意願，對於產生良好的解決方案和有意義的軟體至關重要。如果想要擅長任何事情，就需要練習，練習，再練習。開發人員如果想從優秀邁向偉大，就需要表現出對問題的激情，並致力於理解相關的領域。
要運用好DDD的原則，需要一個積極主動的團隊——一個致力於學習技術及問題領域的團隊。所有人都有激情。如果你對DDD的實踐感到有價值，那麼就可以挺身而出，來鼓舞團隊，並成為一名佈道者。激情是具有感染力的。如果能花時間與領域專家一起更深入地理解業務，並向大家展示由此能獲得更具表達力的代碼庫，那麼其他團隊成員也會追隨你。
對問題空間充滿激情，積極主動，保持好奇。這樣能更容易地找到解決方案，另外更重要的，這樣還能更容易地發現機會。如果沒有足夠深入地理解所涉及的領域，那麼就無法有效解決問題，也無法抓住機會。作為收入頗豐的專業人士，理解所涉及的領域是應盡的責任。
5.2. 要學習解決方案探索的引導過程
要想理解複雜的問題領域，從而創建一個簡單且有用的模型，深入的知識和深刻的洞察是必要的。而這些只有與徹悟領域知識的專家持續地協作才能獲得。但複雜的問題域包含大量信息，其中一些信息並不適用於解決手頭的問題，而只會分散建模工作的關注點。所以就需要知識消化這一從問題領域中提煉相關信息的技術，來構建有用的模型。
領域知識是關鍵，甚至比技術知識更重要。工作於複雜業務流程和邏輯中的團隊，需要將自己沉浸在問題領域中，像海綿一樣，吸收所有相關的領域知識。這種洞察力將使團隊能夠專註於最主要的問題，並在其應用程序代碼庫的核心創建一個模型，以在應用程序的整個生命週期內，持續滿足業務用例。
要又快又好地從領域專家那裡提煉知識，引導技能至關重要。引導者並不需要成為最聰明的人，但需要能夠與聰明人進行協作，引導他們獲得深刻的洞見。引導者只有問對了問題，才能促使人們做出決策，分享知識，找到並達成解決方案。恰如在原則1中所述，Alberto Brandolini在此方面做了大量工作——創造了事件風暴和全局可視化建模的實踐。這種實踐也可用於較低層級的解決方案的探索。
引導過程的關鍵，並不是指導人們找到答案，而是讓他們達成共識，並給他們賦能來擔當相應責任。這不是領導一個團隊做出優秀的決定，而是要確保擁有一個能做出優秀決定的過程。工作坊和協同工作必須要創造一個平臺，以此接納不同的觀點。不存在良策的權威，也不存在愚蠢的建議。
5.3. 在約束中刻意發現
BDD的創造者Dan North提出了一種能對領域知識的獲取進行改進的方法，稱為刻意發現。在規劃和需求收集階段，不要拘泥於敏捷方法論的框架，去做諸如計劃撲克和故事創建的事情，而應該花時間去搞清楚所不瞭解的問題域。領域知識越多，建模的工作就會做得越好。在項目開始時，團隊應該齊心協力，來識別他們最不瞭解的問題域，以確保在知識消化會議期間，能理解這些問題域。團隊應該使用知識消化會議，來識別未知的未知，即那些尚未發現的領域。這個過程應該由下面這樣的領域專家和幹係人來主持，他們能幫助團隊專註於重要的領域，例如已被識別的約束或瓶頸，而不是簡單地消化整個問題域。這樣能讓團隊識別在領域知識上所存在的差距，並能快速進行彌補。
5.4. 但求有影響力的機會，莫問還有多少個需求
「人類知識的最低級形式其實是意見，因為可以不必對所提意見負責，也無須理解上下文。而知識的最高級形式，卻是共情。因為這需要我們暫時放下自我，生活在另一個人的世界中。共情源自重大目的，而非自認為是。」 —— Bill Bullard
業務用戶對現有軟體提出功能增強的需求時，要小心。因為這些需求經常會基於當前系統的約束，而不是他們真正想要的價值。捫心自問，追著用戶去了解需求背後的真正動機，這種事會發生幾次呢？真的理解要做的東西背後的原因了嗎？一旦分享並理解了客戶的真實需要，經常就能提供更好的解決方案。如果客戶真的這樣被人追著時，通常都會感到驚訝，而且緊接著會說出一句經典的臺詞：「哦，真的嗎？原來你還能這麼做！」切記：你纔是推動者。不要盲目地遵循用戶的需求。業務用戶可能無法編寫有效的產品特性，也無法表達有效的產品目標。所以必須要分享和理解他們最基本的願景，瞭解業務正在努力實現的目標，這樣才能提供真正的業務價值。
需求會假設某人已經知道了所有的答案，而這是一個天大的謬誤。我們已經走過了直接從人們那裡收集需求的階段。現在應該能夠和業務夥伴合作，來解決他們的問題，帶給他們讓步的藝術，提供可以帶來無限機會的技術。切記，要擔當，莫偷懶。不要將解決方案的設計甩給業務人員來做。這不是他們要解決的問題，而是你要解決的問題。領域專家並不是系統專家，要與他們一起學習和探索。我經常發現，領域專家既不瞭解當前系統如何工作，也不瞭解這個系統應該如何工作。因為他們雖然是領域專家，但也僅是所在領域的專家，他們既不是業務流程工程師，也不是系統專家。
5.5. 專註於最有趣的部分
「不存在經驗獲取的壓縮演算法[8]。」——Andy Jassy，AWS首席執行官
業務和開發團隊之間的協作，是DDD的基本要素，也是開發產品成功的關鍵。其中最要緊的，是要找到相關領域的行業專家，他們能提供對問題域更深入的洞見。在DDD中，這些行業專家被稱為領域專家。他們是一羣對業務領域有深刻理解的人，既精通業務的策略和流程，也熟悉業務的縟節和「怪癖」。他們雖然是該領域中業務的專家，但很少會擁有領域專家的頭銜。所以應該從產品負責人、用戶或任何能很好掌握和理解相關領域的人中去識別他們，而無須在意他們的職位。
在挑選場景進行建模時，應該去挑困難的部分，即深藏在覈心領域中的有意思的部分來建模。而不要挑「軟柿子」，即不要挑那些簡單數據管理的場景。這如同自行車棚的隱喻，即在面對一個較大問題時，將多到不可理喻的時間和精力，花費在其中微不足道或無關緊要的細節上。該術語來自一個開會的故事，會議的議題是討論核電廠開發，其中大部分討論時間花在了員工自行車棚的設計上，因為這是唯一每個人都能夠理解的部分。
因此，應該專註於產品所特有的那部分業務進行建模。雖然這可能很難，需要時間進行澄清，但在這些方面所花費的時間，將是最值得的，也會讓與領域專家的合作變得卓有成效。如果使用領域專家的時間，來討論簡單的創建、讀取、更新和刪除（CRUD）操作，那很快就會讓討論變得無聊。領域專家不久就會失去興趣，不再想花時間進行討論。DDD原則的目的，就是要對作為產品核心的複雜領域進行建模。
5.5.1. http://PotterMore.com的核心關注點
http://Pottermore.com是網上唯一可以購買哈利波特電子版的地方。與任何電子商務網站一樣，該網站允許瀏覽產品，將產品存放在購物車中，然後結賬。Pottermore網站的核心領域，並不是客戶所能看到的，而是客戶所看不到的。Pottermore的電子書，並不靠DRM鎖定，而是靠水印來保護版權。這種不可見的水印可以用來跟蹤購買過的書籍，以防它們被非法地發布在網路上。Pottermore系統的核心領域是這樣一個子域，其水印技術既能使阻止圖書的非法分發，也不會讓客戶感到受約束（客戶可以將圖書複製到其所擁有的任何其他設備上）。這一對業務來說最重要的點，區別開了其他電子書賣家，確保圖書只能在所構建的系統上銷售，而不會出現在iTunes或其他電子書賣家那裡。
5.6. 確保每個人都理解解決方案的願景
可以在項目開始時，創建領域願景聲明，以此明確給出軟體成功的核心定義、業務目標以及價值。這個聲明應該共享給團隊，甚至可以貼在辦公室的牆上，提醒大家為何要編寫該軟體。
5.6.1. 亞馬遜的產品開發方法
在領域願景聲明方面，亞馬遜擁有一個名為逆向工作法的獨特方法。在產品新的增強功能開發前，產品經理會編寫一份宣佈該功能已完成的內部新聞稿，其中會列出該功能所帶來的好處。如果目標客戶感覺不到令人興奮或有價值的好處，產品經理就會修改新聞稿，直到該功能可以為客戶提供真正的價值。在任何時候，亞馬遜都專註於客戶，並在動手開發新功能之前，都能清晰定義該功能可以給客戶帶來的好處。（未完待續）
作者：Scott Millett
譯者：ThoughtWorks 鄢倩
校審：ThoughtWorks 伍斌、覃宇、徐培、黃雨青
注釋：
【7】Theodore Levitt是哈佛商學院營銷學教授，提出過「營銷近視症」。上面這句話意思是人們真正需要的不是產品，而是完成自己的工作。所以商家應該以用戶的真正需求為導向，設計自己的產品——譯者注
【8】這句話的後半句是：不走點彎路，是獲得不了某些教訓的——譯者注
【2019領域驅動設計峯會】再度啟動，熱力回歸！
峯會購票鏈接：https://mp.weixin.qq.com/s/UO7wpVWfgV7mg5f49vt-KQ
【2019領域驅動設計峯會】再度啟動，熱力回歸！
推薦閱讀：