經驗分享：在金融企業中實施領域驅動設計的敏捷實踐 | 敏捷聯盟

1.引言
我的名字是Kenny Baas-Schwegler。我是一家名為Xebia的荷蘭諮詢公司的戰略軟體交付顧問。我將工作重點放在軟體架構以及我們如何在一個稱為“社會技術架構”的混淆中設計團隊和軟體，並將這些與業務目標高度一致。我透過促進視覺會議來做到這一點。我在混亂中茁壯成長，但我專注於開發結構化軟體。
多年來，我參與了幾次轉型，從DevOps到Digital再到Agile。這些轉變通常側重於將人員轉變為不超過8人的近自治團隊，他們將以敏捷的方式工作。我所工作的每家公司都在這些轉變中提出了同樣的問題：我們如何在團隊之間劃分當前的軟體，以及我們如何使這些團隊與我們的業務架構保持一致？
為解決這些問題，公司請求我幫助使用領域驅動設計（DDD）方法設計微服務。這種方法使得基於已識別的邊界（稱為“有界上下文”）更容易在團隊之間分發軟體。
雖然我認為參與敏捷轉換的企業至少需要一種域驅動設計方法來建立具有鬆散耦合的自主對齊團隊架構，這個過程提出了獨特的挑戰。在這份經驗報告中，我分享了使用DDD將金融企業轉變為敏捷自治團隊六個月的經驗。我還更廣泛地討論了我認為最有效的DDD實踐。

2.背景
我對結構化軟體和架構的關注可能源於我在嵌入式電子工程方面的背景，其中設計精良的印刷電路板至關重要。憑藉我幼稚的學生頭腦，我成為大型金融公司的軟體工程師，並對軟體設計過程過於複雜感到震驚！
觀察這個爛攤子，我開始尋找為什麼會出現這種情況的答案，並找到了一本由Eric Evans撰寫的大藍皮書，名為“ 領域驅動設計：解決軟體中心的複雜性”（2003）。我發現這本書很有挑戰性，因為這不是你在一週內閱讀的內容。
我在工作中苦苦掙扎，因為我工作的公司也做了敏捷過渡，需要在一半的時間內完成兩倍的工作。該團隊正在努力將自己劃分為敏捷團隊。儘管有大量的知識共享，但單體軟體應用程式很難切分開。我們從一個團隊的14人開始。雖然我們開始使用的敏捷框架Scrum已經幫助我們管理了我們的工作，但我們當然沒有在一半的時間內完成兩倍的工作。我的直覺告訴我，DDD會幫助我們分成更多的自治團隊。但由於DDD對我來說太新了，我無法將這個想法賣給管理層。
對我來說幸運的是，應用程式重新設計使其成為我們的待辦事項，這是嘗試DDD的最佳時機。我們能夠劃分該應用程式並降低與現有環境的耦合。我們從兩位開發人員和產品所有者開始。在幾個衝刺中，我們能夠安全地進入生產而不會損害當前的應用程式。這對團隊來說非常成功，因為我們現在可以在內部應用DDD研討會。我們也知道我們現在能夠使用DDD來處理軟體架構。
五年後，我發現我不是因為使用新技術而是來自解決複雜領域而感到高興。因此，我離開了我的第一家公司併成為了一名顧問，以進一步提高我在複雜領域的軟體架構方面的技能。本報告將描述我在諮詢過的公司中目睹的幾種模式，重點介紹我在Lowlanders的經歷。

Lowlanders是一家銷售靈活抵押貸款的重要金融公司的一部分。業務和IT是組織結構圖上的獨立部門。在我加入之前，他們有一個遺留的單片“大泥球”應用程式景觀，這在大型金融公司中很常見。他們已經開始進行敏捷轉型，IT部門正在徹底改革他們的IT環境，將微服務作為解決方案來解開他們的“企業義大利麵條”。
IT部門經理聘請我諮詢DDD。我需要幫助解開他們的系統環境並將其轉換為自主團隊，他們將在新技術堆疊上構建微服務。

什麼是領域驅動設計？
領域驅動設計是軟體開發的整體方法。Eric Evans在他2003年的書中創造了DDD，解決了軟體團隊在自主構建軟體方面遇到的困難。多個團隊設計和構建複雜的解決方案作為單片軟體，通常只使用一個模型來解決許多不同的問題。他還討論了業務所使用的語言與模型中的語言之間的模糊性，從而導致團隊內部和團隊之間的混淆和糾纏。
這種模糊性的一個很好的例子是公司對客戶的看法。公司通常只從一個角度考慮客戶，但實際上客戶有多種不同的背景。例如，在荷蘭，客戶通常可以每年註冊一次新的健康保險。為此，客戶必須在新年開始之前取消舊保險，並在一年的前兩個月內購買新保險。大多數荷蘭人在新的一年前一到兩個月轉換保險公司以保證安全。在這一年的最後兩個月，如果健康保險公司只在一年中的其他時間看待客戶，那麼它們就是有限的。雖然已轉換為公司政策的客戶尚未成為保險客戶，但他們可能會遇到需要解決的問題。在這種情況下，公司需要將其視為有資格獲得客戶支援的客戶。在這個例子中，我們看到很多歧義和許多例外。
為了解決這個問題，Eric建立了有界上下文的概念，這是一種基於一致語言模型劃分軟體的模式。在有界的上下文中，我們透過業務專家和軟體人員之間的對話建立共享語言。這成為無處不在的語言。我們專注於一種簡潔描述領域內情況的語言。我們建立了幾個有界的上下文，而不是一個規範的語言，每個上下文都有自己特定的語言和模型。
在有界的上下文中，當團隊成員開發軟體時，一個團隊可以獲得其模型的所有權並增加其自主權。他們可以單獨測試，因為團隊可以清楚地瞭解他們的客戶是誰，並且可以接收他們自己的反饋指標。Nicole Forsgren博士，Jez Humble和Gene Kim（2018）的研究表明，持續交付績效和成功組織擴充套件的最強預測因素是鬆散耦合的團隊，這些團隊透過鬆散耦合的軟體架構實現。如果你想要加速，這使得有界上下文成為一個非常重要的模式！

領域知識 - 問題空間
雖然使用有界上下文在DDD中劃分模型可以提高自主權，但我並不相信團隊的完全自主權。系統和團隊之間總會有耦合。只有透過設計清晰的界限，並透過決定事物在界限之間移動的位置和方式，我們才能創造自主權。使用有界上下文模式，我們可以降低團隊之間的耦合，併為每個團隊提供獨特的目的。
定義明確邊界的第一步是獲得領域的知識。我在與Lowlanders合作的早期就​​發現了這一點。我的第一次會議涉及幾個業務利益相關者，產品所有者和許多開發人員。產品所有者和業務利益相關者都擁有大量的領域知識，這感覺很棒，因為我知道至少在房間裡有合適的人。
在兩個小時的會議之後，所有開發人員對結果感到非常興奮，他們說：“我們終於可以更深入地瞭解我們需要構建的軟體。”然而，利益相關者和產品所有者並不那麼開心。在一次私人談話中，他們告訴我，“我們已經知道所討論的一切。”
在與開發人員交談時，我還了解到他們每個人都使用不同的業務描述，並對業務領域有不同的看法。
這個例子表明，如果團隊缺乏對域的瞭解或對域有不同的理解，那麼為企業設計有界的上下文是很困難的。如果缺乏這種知識，IT團隊將無法構建合適的軟體，業務，最終客戶將無法獲得他們真正需要的東西。
因此，為了對我們的領域有一個共同的理解，我們必須首先深入瞭解我們在DDD中所謂的“問題空間”.Mathias Verraes將問題空間解釋為“我們認識它的世界。”這是問題、模型和業務架構。作為軟體工程師，我們必須充分了解問題空間以構建正確的解決方案，而同時作為為這些問題開發解決方案的軟體工程師，我們必須親自了解問題的知識。更重要的是，我們必須繼續瞭解問題空間。雖然問題空間通常是穩定的，但是當我們獲得新的見解時它會發生變化。

這些見解可以來自業務方面或來自軟體工程師。這是一項集體努力，這一事實構成了領域驅動設計中的最大問題。在大多數企業中，軟體團隊被視為工廠。您為團隊提供功能性設計，他們將提供軟體。事實並非如此，因為正如Alberto Brandolini所引用的那樣：“不是領域專家知識進入了生產中軟體，而是開發人員自己的見解。”（banq注：盲人摸象）

協作建模的集體知識
我們可以從業務架構中掌握很多領域知識。在過去，我發現即使公司有業務架構，它通常也會過時或與公司的集體看法不一致。這是文件的整體問題。文件確實在知識獲取中至關重要，但是沒有記錄為什麼做出這些寫在文件上的決策的歷史知識，我們很難建立當前架構的文件歷史軌跡並使其保持最新；如果你使用圖表和視覺化形式的文件，這些還是需要建立它們的人的解釋，以便其他人獲得見解。
不幸的是，Lowlanders沒有業務架構，所以我們需要建立一個。最好的方法是收集公司內部的集體知識。
此過程需要面對面的協作建模。要進行協作建模，我們必須邀請集體瞭解整個業務線的合適人員參加六到八小時的會議。在我在洛朗德任職的開始時，很難找到這些人的名單，而且當他們全部可用時，幾乎不可能找到一個四到六個小時的時間段。因此，我依靠IT經理告訴我合適的人是誰，並找到一個“最佳點”：他應該是可以獲得最多知識最多的人。
傳送邀請也帶來了挑戰，我們如何向本來就沒有多少空閒時間的重要業務利益相關者邀請參加這樣的研討會？政治化和良好的營銷在這裡派上用場。如果我能弄清楚他們的痛苦並將其與參加本次研討會的好處聯絡起來，他們就會更願意來。在Lowlanders，我聯絡了利益相關者並進行了公開訪談，這樣就能讓他們明白研討會會解決他們的痛點。
當我有足夠的資訊時，我確定了合適的時間並邀請所有人。我確保擁有最多知識的基本人才能來。我還想讓會議對所有相關人員開放。我總是想要包括人，因為他們擁有的洞察力越多，他們的業務和軟體就越好。但是，我確實需要管理邀請的數量。我只有兩位同事來幫助這個研討會，我只能親自為30位積極貢獻的人提供幫助。

使用EventStorming進行視覺化會議
一旦我們讓每個人都在同一個房間裡擁有正確的知識，我們就可以進行協作建模了。為了從協作建模會話中獲得最多的領域知識，我們需要以與傳統會議的方式不同的方式開展會議。你可能對這些傳統會議非常熟悉，我們坐在桌子旁討論事情。
學習很複雜，沒有一種統一的學習方法。然而，大腦科學展示了我們如何更有效地學習。我發現Sharon Bowman在她的線上文章“六張王炸six Trumps ：製造訓練棒的大腦科學”中討論的"六張王炸"特別有用：

1. 運動勝過坐著。
2. 說話勝過聽力。
3. 影像勝過言語。
4. 寫作勝過閱讀。
5. 更短勝過更長。
6. 不同勝過相同。

這不只是關於IT的
為了獲得對整個域的共同理解並開始設計有界的上下文以轉向自主對齊團隊，我使用了一種名為“Big Picture”的特定EventStorming格式。我在Lowlanders的Big Picture EventStorming會話中的第一步是要求參與者開始寫入領域事件。領域事件相對易於理解。就是已經發生或可能發生的事情，這對於業務來說非常重要。Lowlanders的例子包括：

• 已收到抵押貸款請求
• 抵押貸款申請透過
• 招標籤字
• 申請遭拒絕

執行時間表
一旦每個人都寫了他們的領域事件，就該著手解決混亂了。我要求參與者從“強制執行時間表”開始。這意味著以他們認為最合適的方式協作構建和合並時間軸事件。我要求他們將兩個膠粘物彼此靠近，並決定哪一個先出現。在有30人的Lowlanders研討會上，一些群體很明顯對特定事件有強烈的感受。當這種情況發生時，這些群體創造了自然知識邊界和不同需求的邊界。這些觀察結果提供了有助於以後設計有界上下文的見解。

為了進一步構建EventStorm，我介紹了關鍵事件的概念。關鍵事件是對業務最重要的特定事件。它們是追隨它們的一切的先決條件。房間裡的人們共同決定一個關鍵事件是什麼。

一旦我們選擇了這些關鍵事件，我們就會開始尋找其中的具體流程。通常，泳道開始出現，對應於特定團隊擁有的業務流程的一部分。然後，我們開始爭論關鍵事件和業務流程的這些部分之間的關​​系。

我們還確定並消除雙重事件。如果兩個事件看起來是相同的，我會請其中一位作者解釋事件的含義。由於語言可能不明確，因此一個領域概念可以使用相同的語言作為完全不同的域概念。例如，Lowlanders以不同的方式使用“pieces”一詞。他們的客戶需要提供“pieces”以證明他們的抵押貸款要求的工資。在另一個背景下，“pieces”一詞描述了抵押貸款的所有組成部分。還稱抵押請求中的“pieces”是“舉證責任”。正如您可以想象的那樣，這種模糊性導致了很多混亂，特別是當我們假設一個術語指的是某個概念時它實際上是完全不同的東西。

因此，您可能想知道我們是否需要規範資料模型。但是，在整個業務範圍內使語言保持一致是不可能的。任何人類學家都會告訴你，語言是流動的，受人們的一時興起。語言應該如此發展。由於語言會發生變化以適應新使用者，因此老使用者會反對並抱怨。而不是建立一個大的規範語言，最好用一致的語言製作更小，更統一的有界上下文。模糊性是微妙的，它無處不在，Big Picture EventStorming揭示了這種模糊性，讓我們定義可能的邊界。

關注事件如何發生以及由誰發生
我遵循指導性啟發式，這表明我們抵制誘惑，不是弄清楚事件發生的原因，而是關注它們是如何發生的。這在EventStorming的早期階段中最重要，在它更加一致和完整之前。當小組圍繞特定事件形成時，我會關注人們的談話方式，並提出開放式問題。
很多人開始準確地解釋他們做了什麼，並遠離紙上的事件。然後，我需要提高我的促進技巧，使談話具體化。每當他們解釋他們如何做某事時，我都要求他們指出一個特定的事件。我還要求他們告訴我誰 - 什麼角色 - 在這個過程中建立這些事件。我在這裡使用一個小貼上將該角色新增到事件中作為其中那一部分。

瞭解EventStorming是否完整的一個很好的方法是在紙上出現人們感到高興的結構。在這一點上，我讓他們建立了整個EventStorm的敘述。我要求一名志願者一步一步地走過每個人的事件流程。在Lowlanders，產品所有者自願這樣做。如果沒有志願者，我通常會自己做。

在Lowlanders會議上，公司的整體商業模式的願景已經開始出現。此時，更多的討論和分歧開始發生。說明這些分歧的有效方法是在紙張上與這些引數對應的位置放置一個鮮紅色或粉紅色的粘滯便箋。如果出現對業務流程的任何其他限制，我們也希望用這樣的便籤來視覺化這些。Lowlanders的這些限制的例子包括：

• 人們仍然需要進行人工稽核，這需要花費大量時間。
• 我們已經掌握了客戶資訊，但我們會將其填入。這不是客戶友好的。
• 我們需要與另一個團隊來回溝通。 

繪製系統，約束和機會
一旦我們在EventStorm中捕獲了整個業務線，我們就可以開始將系統對映到它上面了。對映系統可以很好地概述當前的應用程式格局以及它與業務的匹配方式。在我們完成研討會之前，我讓參與者寫下我沒有提出的限制，我也讓他們增加了重新思考機會。
重要的是，人們花時間閱讀這些新增內容，並且每個人都有機會在沒有其他人插話的情況下談論這些內容兩分鐘。這創造了對彼此的挑戰和關注的共同理解。

在一天結束後我們完成了研討會，並要求每個人投票給他們認為最有助於整個業務的約束或規則（banq注：發現隱藏背後的業務規則）。
我們給每個人兩個箭頭放在牆上，表明他們的選票。得票最多的人成為“約束理論”，這是需要解決的瓶頸。

EventStorm導致對業務的共同理解，業務流程中出現約束的情況以及新興邊界。將完成的紙張留在牆上作為EventStorm的快照非常有用。這允許參與者向其他人解釋結果。我們希望保持原樣並且在研討會結束後不做任何改變。雖然我覺得把它留在牆上是最有效的，並且有人在那裡向那些不在那裡的人解釋它，我們也可以錄製一個解釋敘述的人的影片。如果需要，我們可以提取這些知識來更新我們當前的文件。

架構設計和設計有界的上下文
“架構設計是系統設計。系統設計是上下文設計 - 它本質上是關於邊界以及權衡。“ - Ruth Malan

經過培訓的領域驅動設計師可以開始在大圖中視覺化緊急的有界上下文。我們將這些稱為“緊急”，因為從全域性概述來看，我們仍然不足為這些有界上下文提供嚴謹性。Lowlanders的問題在於人們沒有接受過訓練來形象化緊急的有界上下文。因此，他們需要一些這種視覺化的幫助。他們的領域專家還需要分享正式的研討會成果。因此，我開始使用緊急有界上下文設計上下文對映。為此，我們可以使用幾種啟發式方法：

• 關鍵事件形成了硬邊界和關係。
• 泳道是潛在的有界上下文。
• 不同的角色是潛在的邊界。
• 領域專家的專業領域是潛在的邊界。
• 需求衝突是潛在的邊界。
• 語言的動詞表達是不同的。

解決方案空間
Mathias Verraes將解決方案空間描述為“我們設計它時的解決方案（並受到您提到的力量的限制）。”

這是我們用軟體架構來管理複雜性的空間，也是我們故意設計一種無處不在的普遍使用的語言的地方，Rebecca Wirfs-Brock對解決模型進行了很好的解釋：“模型是對事物或現象的簡化表示，故意強調某些方面而忽略其他方面。具體使用的抽象記在心裡。除非你故意遺漏或過分強調誤導，否則沒有錯。“

設計軟體團隊並與業務保持一致 - 社會技術架構
在Lowlanders，我們現在採用緊急的有界上下文，邀請可能在該領域（和其他相關人員）中實施軟體的團隊，並啟動另一個協作建模會話。
這一次，我們使用流程Process和Software EventStorming來清楚地定義我們的有界上下文並設計一個解決問題的潛在模型。我們可能會使用其他技術（如示例對映，影響對映或使用者故事對映）來開始更多視覺化。
在場的團隊可以決定哪個團隊將開始研究哪些有界上下文，他們將如何與業務保持一致，以及他們將使用哪些戰略模式。當然，由具有經驗和知識的架構師執教。

設計所有團隊成員的軟體可以建立共享理解和共享所有權。我們希望設計高度符合商業價值的團隊和軟體，我們稱之為“社會技術架構”，以確保我們從商業理念到生產的交換最少，建立自主協調的團隊。

結論
領域驅動設計和大圖片EventStorming是分享知識和建立整個業務線共享願景的強大工具。在這個共同願景中，我們還可以共同確定對我們業務戰略的最重要限制。單獨改進系統的每個部分永遠不會產生與整個系統相同的結果。我們希望在最重要的地方改進我們的工作，在他們對提高績效產生最大影響的領域。大圖片EventStorming會議是視覺化此變化的絕佳機會。

我在Lowlanders觀察到的是，如果業務沒有分配時間，IT團隊就無法採取行動，也不想做任何事情。例如，工程師團隊並不總是有時間學習構建正確事物所需的領域知識。團隊很高興參加EventStorming會議以增加他們的領域知識，但產品所有者抱怨說，“我已經知道所有這些，而且需要花費很多時間。”

在與產品所有者討論之後，我可以理解他們的觀點。他們的管理層也有同樣的情況。他們有目標，他們需要確定性。因此，如果我們想要開始建立更好的軟體，那麼業務和IT之間的一致性就至關重要。
為了實現一致性，我們需要停止在業務和IT方面進行思考，並開始作為一個整合的團隊。

EventStorming透過打破業務和IT之間的障礙來幫助我們實現這一目標。它使我們能夠分享有關我們的工作，我們為什麼這樣做以及我們如何做的知識。透過設計有界的上下文，我們可以確保單個團隊擁有獨立開發和釋出符合業務目標的軟體所需的自主權。這並不容易，但在我看來，這是建立優質軟體和與更快的魚一起游泳的唯一方法！