電話機器人團隊 DDD 實踐
簡介
DDD 是一套方法論，一套思想。種類繁多的元模型和名詞概念。其本質都是指導思想對應的解決方案 “之一”，初學者容易被表象所困。應始終清醒保持認知 “DDD 各種元模型都是爲解決實際開發中某類問題而起”。在接觸各類元模型時應結合自身業務面臨問題來求證，這樣有助於避免被概念表象所困，迴歸解決問題的本質。
背景
數據架構團隊從 18 年開始，受業務需求驅動開發電話機器人，轉眼已近 5 年。目前，在該平臺下已搭建 100 + 不同類型機器人，爲公司經銷商、二手車、主機廠、金融等多個 BU 業務提供外呼能力，日外呼量幾十萬通。電話機器人項目已初具規模，但過程中也遇到不少挑戰。爲了應對這些挑戰，我們團隊最終採用 DDD 思想進行重構和開發。
在應用 DDD 的過程中，數據架構團隊落地了一些自己的開發規範。這裏就把一些經驗和想法分享給大家，希望能起到拋磚引玉作用。這裏解釋一下，篇幅中很多元模型沒有展開講，也沒有給出具體案例。一是考慮到篇幅長度問題。二是理解了 DDD 思想，結合各自業務來實現就好了，給出在我業務的例子意義並不大。此外這類案例很容易找的到。同時，覺得給出我們團隊遇到的問題、解決方案，落地過程和我們形成的開發規範對大家來說更有價值。對 DDD 感興趣，想了解更多或對本文有疑問的同學，歡迎找我交流討論。
下面，我從這幾個部分來進行分享：機器人項目中遇到的挑戰、爲什麼是 DDD、DDD 落地步驟、對團隊帶來的提升、理論到實戰遇到的衝突以及未來在 DDD 應用方面的改進和總結。
1. 遇到的挑戰
► 挑戰一： 業務邏輯複雜度高。隨着各類業務的接入，爲應對不同場景下的特定業務，不斷追加新邏輯。
如：流程中的意圖識別邏輯。
意圖識別需要依賴 AI 的多個模型識別，多個模型識別出來的意圖有可能是衝突的，需要對沖突的意圖配置規則做取捨。同時，對一些冷啓動或者緊急優化的場景，需要支持通過配置規則實時生效的方式來意圖識別。並且在規則的意圖識別中需要支持匹配詞槽。詞槽的類型又有多種，從優先級上區分有場景的全局詞槽、流程上的詞槽。從數據識別來源上區分，可以分爲 AI 識別出來的，詞典規則匹配出來的，還可能是業務方傳遞進來的。業務開展一段時間後，不同類型的詞槽又增加不同屬性，如車系的詞槽有本品、經營範圍、非經營等等；
► 挑戰二： 代碼架構結構不清晰。隨着業務需求功能的追加，伴隨着代碼規模增大。加之邏輯複雜和團隊開發人員代碼迥異，逐漸導致各種邏輯邊界變得混亂。
如：我們通常的開發方式，按功能模塊拆解，業務流程串聯協調各個模塊，共同完成業務需求。但是處理這類業務複雜的邏輯，這種方案設計有很大的弊端，模塊邊界很容易被穿透。
各模塊關係相互調用，原本作爲模塊的隔離設計，實際在實現過程被完完全全的打破了。使原本理想中垂直拆分的模塊，變成網狀的結構。
模塊負責人中間環節開發出來的的屬性或方法，被外部其它模塊外依賴導致功能發散出去。導致後期需求變動時風險增加，又或是發現被依賴了原本可以隨意更改的方法不能變動，不得不增加額外邏輯代碼來實現。造成了本就複雜的代碼更加複雜。
對業務需求拆解不合理，需求功能在實現時就近開發，未嚴格按照模塊拆解，缺少統一思想作爲指導。
► 挑戰三： 產品需求多，難以辨別是否有真實價值。
► 挑戰四： 邏輯變化快，不少需求導致需要代碼邏輯重新設計。
► 挑戰五： 業務多，各業務表述不一致，溝通成本高。
垂直邊界被打破，代碼複雜度增加，加上業務流程頻繁調整。這些多重維度相互疊加，使得開發和維護難度指數增加。電話機器人這個一級應用系統的穩定性難以保障。即便技術同學都是資深的工程師，已經按照所能理解的微服務思想設計、按照模塊拆解項目，即便代碼邏輯中已經也引用不少設計模式來構建與擴展，即便已經是接入了公司各個平臺質量工具、寫了不少單元測試。但是在項目新需求迭代時，依舊出現不少 “驚喜”，使整個團隊很頭疼。
2. 爲什麼是 DDD
爲什麼是 DDD？每天那麼多技術棧，那麼多思想，爲什麼就是 DDD 來應對呢？首先 DDD 修飾的很好 “軟件核心複雜性應對之道”，使得不少人想一探究竟。所以來看看 DDD 是怎麼來解決項目中遇到的挑戰。
► 首先，我們來看看 DDD 對複雜度的歸類，弄明白 DDD 要應對的複雜度是否是我面臨的挑戰。DDD 相關資料中，從理解能力和預測能力兩個維度來探索剖析複雜度的成因。
理解能力 (就是軟件系統對開發人員來說複雜難以理解)：
第一規模：影響理解能力的第一要素。幾百上千萬行的代碼，各需求點的關係相互影響。修改一處就會牽一髮動全身。
第二結構：不合理甚至混亂的結構，導致開發人員對功能難以維護。
預測能力 (就是業務的發展難以預測)：
當需求變化時，難以預測軟件實現的走向，會出現過度設計和設計不足問題。過度設計，預留了很多接口，構造了很多模式增加了代碼的實現複雜度，但後來發現用不到。設計不足，需求的實現沒考慮到後期的發展，當變化來臨時需要推翻現有設計重新開發，被產品抱怨設計能力差。
DDD 對複雜度的成因歸結爲：規模、結構、變化；規模和結構製造了理解能力障礙，變化製造了預測能力障礙，兩者相加形成了複雜度問題。
► 其次，DDD 並不僅僅是對代碼設計階段的理論，而是還包含從需求分析、架構映射和建模及實現的全流程設計指導。
需求分析階段，通過相關指導思想提前準確獲知業務價值，捕獲未來變化方向。架構映射階段，給出從需求到架構過程的指導思想，增加了設計權重和規範。通過子領域拆分、系統分層和限界上下文業務歸類，給出指導規範，保障了系統架構的清晰，並且降低系統複雜度。建模及實現階段，給出來領域驅動設計相關元模型，使各部分職能分工明確，快速響應業務需求和未來功能變化。
► 再次，來看 DDD 給出的指導思想：
規模問題：拆邊界。以子領域、限界上下文對拆解分治。
針對分治思想，DDD 給出兩個重要的設計元模型：限界上下文和上下文映射。
結構問題：分層架構 + 限界隔離。
分層起到了隔離業務邏輯和技術實現複雜度問題。DDD 引入的分層架構，將業務邏輯封裝到領域層，支撐業務邏輯的技術實現放到基礎設施層。在領域層之上的應用層封裝應用服務，粘合二者進行協作。
變化問題：主動設計變化。
變化無法控制，只能擁抱變化。需求分析階段運用 5W 思維識別變化規律，把控業務變化。DDD 通過模型驅動設計元模型對限界上下文進行領域建模，形成結合分析、設計和實現一體的領域模型。
►最後，來看 DDD 給出的解決方案。其引入了一套提煉爲模式的設計元模型，對業務軟件做到了對規模的控制、結構的拆分以及變化的主動響應。
簡單介紹下這張圖，整體分爲兩個大部分。第一部分是下面虛線圈出來的部分，不涉及具體技術實現。在需求分析階段進行的，應對問題空間的一些元模型方案。另外部分，在第一部分的基礎上，做具體系統架構分層、對象抽離聚合、服務拆解環節，這個階段做對應的設計落地。
我的理解是這樣，這套設計元模型給出了從需求分析、設計和實現一體整套解決方案。需求分析階段的系統拆解 (對應圖中子領域元模型)。再拆到更新粒度的限界上下文。並給出各限界的協同關係方案（對應圖中上下文映射元模型）。設計實現階段給出模型驅動設計的設計元方案, 通過系統的分層架構、領域服務、聚合等粒度的設計。給出一套完善的、有理論支撐的、可落地有標準的解決方案。
上述 DDD 對問題複雜度的剖析定位，完全就是電話機器人系統中的痛點。給出的解決方案，也完美解決業務面臨的各類挑戰。認識到其價值後，團隊很快達成共識在後續的項目中進行落地。
3. DDD 落地步驟
元模型細節、業務限界的拆解不展開講了，直接給出我們團隊實戰中的步驟和產物。
3.1 第一步預研階段
這部分我們的經驗是團隊中有人充當先行者，先花費精力做深入學習 DDD 相關理念，然後同步到整個團隊。就我們團隊來講，調研階段時間比較零碎不好評估用時多久，團隊科普階段前後 4 次用時 8 小時。之後，團隊內同學在有概念指導的基礎上，已具備快速深入學習能力。並組織團隊成內相互探討印證理解。
3.2 第二步引入指導思想和落地規範
►3.2.1 需求分析階段引入 5W 模型理論支撐，有助辨識出真實需求，主動把控變化方向和排除無意義需求。
這部分就是 5W 理論作爲跟產品分析需求的理論的支撐，非常有助於識別出真實的需求，更好的分析出業務的發展方向。也能從源頭上縮減無效需求，直接上圖；
►3.2.2 引入服務規約，以文檔型對照代碼業務功能實現。有助於開發及後續需求梳理，同時也能作爲單元測試覆蓋度的考量。
⬤ 3.2.2.1 團隊成員共識，需求先寫服務規約，再做開發。寫服務規約的時間，其實就是技術對需求理解的梳理，理清了思路，後續寫代碼時把這部分時間賺回來。
⬤ 3.2.2.2 服務規約及需求，服務規約即對應單測。順帶解決了先前單測沒有標準 (我理解的代碼、方法覆蓋率這類，不能稱作爲標準) 的問題。
►這裏給出我們團隊採用的服務規約模板：
編號：標記業務服務的唯一編號。
名稱：動詞短語形式的業務服務名。
描述：
作爲 <角色>
我想要 <服務功能>
以便於 <服務價值>
觸發事件：
角色主動觸發的該業務服務事件，可以是點擊 UI 的控件、具體的策略或伴生系統發送的消息等。
基本流程：
用於表現業務服務的主流程，即執行成功的業務場景。也可以稱之爲 “主成功場景”。
替代流程：
用於表現業務服務的擴展流程，即執行失敗的業務場景。
驗收標準：
一系列可以接受的條件或業務規則，以要點形式列舉。
3.3 第三步確定架構方案
學習 DDD 中模型驅動設計元模型的方案。主要是劃分職責邊界，也就是限界上下文，達到從傳統網狀結構關係變爲垂直切分關係，減少彼此依賴。整體採用限界上線文拆解加菱形驅動設計，形成整體思想指導。系統採用分層架構 COLA 4.0
3.4 第四步共識命名標準
形成團隊編碼規範
團隊內共識包命名、類命名、出參入參的消息契約等規範。這裏想說的是參考標準就是沒有標準。希望大家先能理解 DDD 思想，然後參照學習業內共識性高的命名方案。同時需要兼顧團隊內成員編程風格喜好，最終來制定自己團隊的編碼規範。
依我們入參、出參消息命名來舉例。綜合各方考量，並沒有採用上圖粒度特別細的命名方式。而是團隊內簡單共識爲入參 * request，出參 * reponse 命名標準。
3.5 第五步
結合業務特徵識別出限界上下文
基於 DDD 思想，對業務進行事件風暴，在統一語言的指導下做全局需求分析、架構映射設計，識別出業務的限界上下文。
技術同學結合自身業務來設計，參照 Demo 資料還是比較容易找的到，這裏不再贅述。這裏給出識別限界上下文的一個指導過程，V 型映射過程。
3.6 最後進入建模的實現階段
建議採測試驅動開發的方式進行編碼，即用紅綠黃驅動；
該方式遵循其三定律，這樣能改善對需求的設計不足和過度設計問題。
4. 對團隊帶來的提升
4.1 被動接收需求到主動應對
需求分析階段，運用 5W 原則。剖析需求的合理性，能主動把控項目的變化方向。解決 “挑戰三” 對需求價值辨別和改善了 “挑戰四” 的把控業務發展變化方向。
4.2 降低溝通成本
運用統一語言思想溝通，降低 “挑戰五” 的各個環節的協作成本。
4.3 架構設計提升
通過設計元模型的子領域模型、限界上下文合理拆解代碼規模。通過 DDD 的分層思想，隔離業務邏輯與技術維度複雜度，清晰代碼結構。同時項目採用菱形對稱結構，通過南北向網關與外部交互，避免了模塊的網狀情況滋生。解決了 “挑戰二” 問題和降低了 “挑戰一” 複雜度問題。
4.4 技術實現提升
團隊在開發業務功能時，會考慮需求放到那個限界合理。實現過程會考慮放到領域層還是業務服務層，功能的實現上採用貧血模型還是充血。
4.5 文檔規範提升
文檔規範上，引入服務規約機制。既能作爲梳理需求的工具，又能作爲單測的依據。同時還爲後期提供了服務說明的文檔。
4.6 代碼實現提升
代碼實現上，從架構到編碼實現、命名，形成了一套有標註的規範。
總的來說，該模式下，團隊的思維方式發生了轉變。通過應用各類元模型，來應對從需求分析到系統架構、代碼實現不同環節帶來的挑戰。
5. 理論到實戰遇到的衝突
5.1 貧血模型 PK 充血模型
貧血模型：通俗來說，就是 domain object 只有屬性的 getter/setter 方法的純數據類，業務邏輯和應用邏輯都放到服務層中，這種模型下的 domain object 被 Martin Fowler 稱之爲 “貧血的 domain object”。
充血模型：反之，充血模型中不僅包含了對象的屬性，還包含了對象的行爲，包括業務邏輯。
從面向對象角度分析，對象是包含屬性和行爲的，理應是使用充血模型，並且 DDD 原則上也是建議採用充血模型。但落地到具體開發現狀，即便是貧血模型有很多問題，但業內存在這麼多年、運用這麼普遍，總歸是有其存在的價值。加上 JAVA 應用大部分採用 Mybatis 技術棧，很多對象是插件自動生成的貧血實體。所以問題來了，採用充血模型意味着一部分便利工具的廢棄。這個問題團隊內分歧比較大。最終我們的方式是這部分不做硬性標準，但建議使用充血模式。
5.2 嚴格遵守數據轉換約束 PK 精簡提效的外部數據直接使用
在 DDD 的思想中，爲了確保領域服務的可靠性。要求領域服務依賴的數據爲領域內的實體、聚合數據，不允許直接使用外部的消息鍥約數據。對應到菱形對稱架構的南北向網關獲取數據的轉換，會帶來額外的工作量。有團隊同學建議某些相對穩定的結構可以不遵守該原則，理由是能提高開發速度，且認爲可能 90% 的數據都是如數據庫這類結構較爲穩定的資源。但最終團隊內還是嚴格要求遵守該指導思想。
5.3 緩存處理 允許共享 PK 限界隔離
同一系統不同限界中緩存處理：允許共享 PK 各限界隔離。
就當時場景來看，允許共享短期內能減少部分工作量、節約資源等優勢。但之所以要劃分限界，就是爲了拆解關係防止過大。這裏給到的建議是，首先考慮共用數據的服務是不是合併爲一個限界比較合理。如果不能合併，必須隔離數據。
5.4 服務規約對照需求的 前端 PK 後端
指導理論思想很美好，需求分析時要求屏蔽技術實現思維。但終歸是要落地到技術棧的，落地到技術實現時就會受技術實現的干擾。當時比較突出的一個問題，功能的實現可以放到前端，也可以後端服務實現。
舉例一：需求要求 “id + 名字” 組合展示，但是後端接口返回的 id、名字兩個字段，實際前端技術棧來組合，那面向前端與後端的服務規約不一致。
舉例二：需求要求驗證參數非空。在一些內部系統中，我們團隊技術都是前後端全棧工程師，分工按需求模塊開發。往往不會特別嚴謹到兩端都做驗證。也導致服務規約面向哪端有衝突。
我們最終的取捨：團隊採用面向後端服務層面。但同時做一些改進，如驗證這類功能轉移到接口層面來實現。
5.5 誰來確保服務規約編寫是否正確 產品 PK 技術
最開始階段理想狀態是由需求側產品來覈驗，本着誰的需求誰確認原則。但由於存在 4.4 的差異問題，我們實際落地是由技術負責人來審覈。
6. 未來在 DDD 應用方面的
改進和總結
DDD 的應用，團隊目前做到了從架構和規範上面進行落地。但一些細節如：聚合類、實體、值對象這些設計，並沒有特別精細。後期會進一步推進在這些細粒度上面的改進。同時，對一些在用的老項目，按照 DDD 思想進行改造重構。
有人認爲應用 DDD 會降低開發效率，這個也是很多團隊的一個顧慮。我們是這麼看待這個問題的，應用 DDD 的場景是解決複雜性業務問題的，確實是會增加代碼量。但不等於降低開發效率。清晰的架構結構、聚合的領域服務和規範的標準，對後期需求升級、代碼維護、複雜度控制帶來的收益，遠大於投入。並且，軟件行業給出的數據，80% 的時間是在需求分析和設計，開發時間只佔到 20%。因此這部分損耗不是重點。
最後，陳述一下使用 DDD 的感受。DDD 各種元模型種類繁多，大家可以根據業務面臨的痛點有目的來學習和採用。在實際的業務環境中，我們的領域模型或多或少的都有一定的 “特殊性”，如果 100% 的要符合 DDD 規範可能成本會比較高，所以最主要的是理解 DDD 思想，最終選擇合適自身業務的方案。
作者簡介
李曉華
■ 經銷商事業部 - 經銷商技術部。
■ 2016 年加入汽車之家，目前任職於經銷商數據架構組團隊，負責電話機器人項目。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/q9939CRaQIHCKoyi2Mj1ng