本文書接上回《先有雞還是先有蛋？這是領域驅動設計落地最大的困局》
https://mp.weixin.qq.com/s/lzAZXgchCg_VyLmyo2N18Q
故事背景
2023年，我加入了一個全新的團隊，擔任技術Leader的角色，可以算做是“空降”吧，至今已經一年有餘的時間了。到目前為止，團隊已經完成了領域驅動設計實踐的內化，需求分析、領域建模、程式碼編寫過程，都遵循了符合領域驅動設計理念的方法，團隊成員的設計思維在實踐的過程中發生了變化，將識別邊界這件事逐步內化成了底層的價值觀。
準備階段
在初入團隊之前，我有過成功落地的經驗，也有信誓旦旦卻草草收場的案例，更重要的是，成功在先，失敗在後，在覆盤和反思之後，我發現，必須在建立足夠的信任的基礎上，才有可能帶領一支團隊走進領域驅動設計的大門，畢竟這是一場價值觀的戰爭，因此，建立信任成為我在準備階段最重要的目標。
要獲得足夠的信任，就需要“上級信任”和“下（同）級信任”，對上做充分的溝通和預期管理，確保目標達成持續符合預期，對下展示技術能力和技術判斷力，給團隊帶來共識的決策和技術的落地，比如分散式的上下文傳遞系統，藉助該能力，系統實現了從單租戶到多租戶的架構變遷，同時也獲得了全鏈路灰度的能力，這個能力我在之前的部落格中有專門介紹。
在團隊中的信任提升，又會形成相互的增強，上級信任的提升，會使得上級對我的決策背書加強，從而增強下級的協作配合，下（同）級的信任又會產生正向的反饋給到上級，增強上級的信任。
當然，我深知這一切的前提是，你遇到的團隊文化是開放的、積極的，否則無論你如何做，都無法建立起必要的信任感。
下定決心
經過了六個月的磨合，我的大部分建議和決策都開始被團隊認可和支援了，我覺得已經做好了準備，只等一個契機，恰好這個機會就來了。
團隊面對一個規模比較大的需求，綜合判斷下來，要滿足該需求基本上類似於重寫一個核心模組，我們面臨的最大挑戰是：老程式碼已經不堪重負，已經團隊已經喪失了對其的控制，迭代速度和交付質量雙雙失控，在這樣的背景下做一個較大規模大迭代，所有人都沒有信心。
而我認為，這是一個千載難逢的機會，可以促使團隊下定革新的決心，經過短暫的思考和準備，最終，我決定，啟用DDD戰術框架來實現該需求。綜合理由如下：
- 團隊對老模式不滿意，按照目前的狀態，交付過程極其痛苦且風險高，大家渴望改善現狀；
- 有成熟的DDD戰術框架，團隊要做的就是進行簡單的熟悉即可，學習成本很低，一週內即可上手；
- 團隊對我的信任達到了比較好的狀態，這個決策大機率會被直屬領導支援；
- 團隊的大部分人心態都是開放的；
於是我花兩天時間，從零開始用DDD戰術框架把專案工程搭建出來，與現有系統整合，並完成了整體CI/CD的配置，讓團隊可以直接上手寫業務程式碼。
隨即，我展開了對後端開發的一對一溝通，為的是確認大家的真實感受，確保大家在整體協作中是足夠坦誠的，因為只有大家的真實反饋，才有利於整個事情的發展，才能夠在前進中不斷修正，從而確保最終的成功。在溝透過程中，我問大家了幾個問題：
- 如果我們保持現在的步調，你覺得自己一年以後會成長成什麼樣子？
- 如果我說現在有一次團隊革新的機會，如果成了，之前我給大家描繪的理想團隊的樣子就會成為現實，你是否願意相信我。
- 如果我說有一套DDD戰術框架，你只需要不到一週，就能駕馭它，你是否原因相信我。
很幸運，大家給我的回答都與我所設想的方向一致：
- 如果保持現狀的步調，未來也不會有太多成長，不會有新的東西，重複CRUD而已；
- 多學一些也無妨，不管是否如“你”所說，最終是否成功，對於自己都是有所收穫的；
- 感覺可能沒說得那麼簡單，但願意試試；
在得到大家的正向反饋後，我就自己對整個事情的想法，與上級進行了溝通，表達了我們目前的困境，以及改革的天時地利人和，最終得到了上級的支援：
於是，我們最終敲定，上新框架，上DDD。
最艱難的時刻
萬事開頭難，我們在引入DDD戰術框架的第一個迭代交付，也是最艱難的階段，雖然有心理準備，但整個過程，團隊仍然承受了比較大的壓力，這些壓力主要來自於：
- 時間緊迫，有限的交付工期；
- 新老服務的銜接工作超出了預估；
所有的問題最終都指向一個緊缺資源，就是時間，於是我們採取了三個行動來確保最終結果是成功的：
- 與業務團隊以及上級坦誠表達，工作量的實際情況，由於實際工作量比預期的要高，團隊最終爭取到了額外的一些研發時間；
- 集體關進會議室，做封閉式開發，我們發現用DDD的編碼正規化，一旦建模完畢，我們可以按照“命令-事件”將一個複雜流程分配給多個開發者，使得團隊能夠快速地協作開發，完成一個複雜功能；
- 團隊組織了一定程度上的加班，這段時間，也是近一年來最辛苦的時刻；
幸運的是，透過這些舉措，我們最終完成了交付，拿到了符合預期的結果。於是，在第一個迭代交付完成後，由產品團隊發起，我們用同樣的方法，完成了一個更大規模的核心模組的重構工作。
這最初的兩個大的迭代，整體持續大約3個月左右，是最繁忙的，最艱難的，又是團隊成長最快的一段時間，後來回想起來，大家也認為是最有必要的。
變化與收益
在第二個重構工作完成後，團隊明顯感受到了一些變化：
- 業務建模，到編寫程式碼不需要做太多的思考，程式碼可以與模型保持一致，不需要做翻譯工作了；
- 對功能的迭代不再有負擔感，感覺程式碼是可以駕馭的，這得益於DDD的程式碼組織方式，使得系統變更的影響範圍，總是容易掌控的，程式碼變動的影響面非常容易掌控；
- 線上問題的修復相比以前更容易，新框架在資料的一致性方面有比較明顯的健壯性，確保資料正確更容易；
我們的工作流也逐步進行了進化：
這裡工作流程最大的變化是：
- 更關注模型的設計是否符合預期；
- 從帶著大家建模，進化為團隊成員可以獨立建模，並基本符合預期；
- 一旦模型確定，程式碼基本就確定了；
- 模型設計完畢後，工作量的估算比過去要準確得多，漏算的情況大幅減少；
意外的收穫
在我們決定啟動DDD落地之前的一個月，我們團隊來了一位新同事，這是一位剛剛畢業的學生，有程式設計的基礎和一段時間的實習經驗，這位同事在整個過程中的表現讓我意識到，領域驅動設計並不是遙不可及的東西，相反它是很底層的認知，對於新人，反倒接受和實踐起來，反倒沒有太大的負擔。下面我列舉一下觀察到的情況：
- 他能夠在一週左右的時間入門並使用DDD戰術框架完成功能模組的開發
- 他能夠在3個月的訓練之後，按照DDD的思路參與建模工作
- 他設計的模型，會因為缺乏經驗而對業務場景的分析不夠充分
基於這些現象，我們發現：
- 在已經落地DDD的環境下，學習DDD會非常容易；
- DDD的戰術框架極其重要，為新人學習降低了理解門檻；
- 要做好建模，需要更多的業務和設計經驗；
我想，如果一個團隊一上來就是DDD的，那麼大家會不會反而覺得程序導向的風格是“奇怪的”呢？
盜夢空間
以上，就是我們團隊整個落地DDD的過程，看似很多關鍵的決策點都有些夢幻 ，團隊為什麼會透過兩三個月時間就轉變了思維，可以用DDD的模式來思考和建模，而這一切的背後，實際上還有一條暗線。
大家應該都看過《盜夢空間》這部電影，整個電影核心講述了“向一個人心底植入一個觀點”的故事，這很科幻。但我覺得我在與團隊一開始相處的時候，就跟大家不斷闡述了領域驅動設計的價值觀，就像在植入觀點一樣，只不過並沒有使用“領域驅動設計”的詞彙。在每一次業務分析、技術方案討論和決策過程中，我都會向大家表達“問題的範圍和邊界很重要”，“方案的範圍和邊界很重要”，“程式碼的職責範圍和邊界很重要”，我不斷地重複“範圍和邊界很重要”，不斷地把“範圍和邊界”與“代價和收益”建立關聯，不斷地用我們遇到的具體例項來對應“範圍和邊界”。
最終，關於“範圍和邊界很重要”這個觀點，獲得了認同，基於這個認同，我們的決策邏輯，趨於一致，我們的建模思維開始共鳴。
終極奧義
雖然為了吸引大家眼球，我標題黨地使用了“PUA”這個詞，但我認為在團隊協作中要取得成功的終極奧義是：
- 真誠是最大的PUA
- 相信“相信的力量”
如果我不夠真誠，沒人會相信我，如果沒人相信，那麼一切都不成立，與大家共勉。