文章簡介

在B端產品研發及專案實施中，DDD帶給我們哪些思考？我們是如何應用的？本文不是科普貼，旨在分享我們的經歷和思考。

背景

Domain Driven Design（簡稱 DDD），又稱為領域驅動設計，起源於傑出軟體建模專家Eric Evans在2003年發表的書籍《DOMAIN-DRINEN DESIGN —TACKLING COMPLEXITY IN THE HEART OF SOFTWARE》（中文譯名《領域驅動設計—軟體核心複雜性應對之道》）。隨著2014年Martin Flower和James Lewis的《Microservice》出版，微服務概念為業界所接受，DDD也被重新提起。人們發現，DDD裡的領域、限界上下文、領域模型等理念，和微服務的高內聚、低耦合理念有著天然契合，越來越多的人把DDD作為指導微服務劃分的方法論之一，也有越來越多的人認為，掌握DDD才是一名優秀的架構師。

DDD工作流程 - 圖片來自於網路

限界上下文 - 圖片來自於網路

為什麼我們要開始DDD？

筆者所在團隊於2015年左右開始進行公司自主產品的研發，當時，DDD主要應用在我們的微服務劃分、程式碼分層中，對我們當時從技術角度出發、搭建統一的微服務技術框架，有著重要的指導意義。而真正開始思考將DDD應用在具體的業務領域與業務場景中，是在2018年末。那時，我們面臨著自主產品實施的專案越來越多、需要幫助客戶從0到1構建業務應用的情況，如何在企業甚至行業的複雜業務場景中找到合適的架構方案，是當時我們期望藉助DDD去更體系化回答的問題。

我們是如何應用DDD的？

在DDD的實踐中，大多數人應該都會面臨一個問題：名詞太多！“領域”、“子域”、“限界上下文”、“聚合”、“實體”、“值物件”等等名詞，令人眼花繚亂。並且，DDD的理論雖然告訴了我們名詞的定義和處理原則，但是具體場景之下，到底如何基於原則去分析，好像並沒有標準答案。

這也是我們在應用DDD時的最大困境，我們也在反覆思考：如何在團隊內統一語言、如何把DDD原則融入到具體可執行的工作事項中？

接下來，我們將從人和事兩個方面來分享我們的經歷與思考。

人：

DDD裡強調，領域專家和開發團隊共同工作。

領域專家的加入，其本質在於讓一切的設計迴歸業務本身，從業務價值出發，聚焦業務核心域，避免過度設計。

希望領域專家和開發團隊共同工作，往往是實踐中的第一個難題，如何找到合格的領域專家？如何保障領域專家的時間投入？如何最大化發揮領域專家的“價值”？

• 關於合格的領域專家：領域專家不是指某一個特定的人，可以是很多人，可相互補充，但同時也不建議過多。在尋找領域專家時，企業可以從自身的業務領域出發，在每個業務領域尋找到有豐富經驗的人員。這裡的“經驗豐富”並不僅僅是一線實戰經驗豐富，更是對業務要有深度的理解和認知。
• 關於領域專家時間投入的保障：在實踐中會發現，有各種各樣的“客觀”原因，導致領域專家無法有效投入。雖然有很多客觀的情況，但是不管有多麼困難，保障領域專家的時間投入都是必須要做的。如果領域專家都不參與，我們怎麼有信心講我們交付的是業務價值而不是一堆程式碼呢？
• 如何最大化發揮領域專家的“價值”：把抽象的問題具象化，通過聆聽和引導，更多地從企業的領域專家處獲得資訊，放棄“我是專家”的執念。

開發團隊：在多數的資訊化專案中，常見的分工是需求分析師進行需求收集與設計，技術人員負責開發和實現，需求分析師進行測試驗收。在DDD實踐時，建議開發團隊的業務架構師、技術架構師、測試架構師從一開始便共同工作，這樣才能夠發揮每個角色在各自專業領域的長處、逐步統一語言、快速達成共識。

事：

DDD區分了戰略設計與戰術設計兩個層次，提出了聚焦核心域、創造性協作、統一語言的三個原則。很多人在剛開始應用DDD的時候，會感覺自己都“不會說話”、“不會做事兒”了。這其實是因為過於關注名詞本身，陷於對名詞的理解和解釋上，因此，在“事”上，我們認為，需要抓住兩個要點。

• 找到更舒服的方式

DDD通過戰略設計解決業務邊界劃分的問題，通過戰術設計實現領域模型的抽象，解決的是從業務到技術的過渡。

在談DDD的時候，一定繞不開事件風暴。“事件風暴（Event Storming）是一種快速的設計技術，讓領域專家和開發人員都可以參與到這個快節奏的學習過程中。它聚焦於業務和業務流程，而非名詞概念和資料。”（摘自Vaughn Vernon《領域驅動設計精粹》）。事件風暴為DDD戰略與戰術落地，提供了一種非常有邏輯、有體系的方法，那麼在這個方法之外，還有沒有其他的方法呢？答案是，有的。尤其在B端企業的資訊化建設中，瀑布實施方法論、敏捷開發等等非常多優秀的方法與工具，都可以為我們所用。

在DDD的落地過程中，我們核心的是要抓住最終要獲得的結果，在過程中所採取的方式，可以根據實際情況進行調整，關鍵是要找到一個讓大多數團隊成員都舒服的方式。以筆者的經歷為例，有一家客戶習慣了以流程圖的方式進行業務梳理，在這種情況下，使用事件風暴的方式會對客戶的習慣造成衝擊，甚至讓客戶不知道如何輸出。此時，我們就應該及時調整，思考流程圖與事件風暴如何融合，既能以客戶習慣的方式推進，同時也能拿到我們想要的結果。

• 將原則與概念形成模板與具體工作任務

一千個人有一千個哈姆雷特，每個人對DDD原則、概念都有自己的解讀。為了更快速地在團隊內達成DDD落地方法的“統一語言”，建議以具體的工作任務、產出物模板來承載，讓團隊更聚焦在目標與任務的達成上。

通過在自主產品的研發和實施專案中應用DDD並持續迭代其應用方法，我們不僅有效地完成了中臺專案的實施、為客戶構建了合理地應用架構，也逐步完善了專案實施方法論體系，為更廣泛地專案交付和產品研發提供了助力。DDD幫助解決了產品架構設計中的一部分問題，在架構設計之後，如何保障設計的落地、高效地交付，是每個團隊會面臨的下一個問題。在這裡，筆者推薦使用豬齒魚這款數智化效能平臺，它可以有效管理架構設計所形成的微服務或模組，拉通設計與開發，通過提供協作、測試、DevOps、容器工具，提高團隊效能。

豬齒魚數智化效能平臺

現在我們是如何理解DDD的？

DDD首先是一種思想，“聚焦核心域、創造性協作、統一語言”，是關於價值發現、價值認定、討論、聆聽、共識、迭代。這種思想不僅適用於軟體設計，也適用於日常工作、個人生活、家庭教育等等方面。我們不可能在每個方面都做到完美，需要識別關鍵要務、聚焦投入；我們也不可能獨自存在，需要與人連線、深度聆聽、積極反饋；我們欣喜於共識默契，也有勇氣接受差異，因為正是這些差異讓我們不斷碰撞、更好地學習與成長。

其次，DDD是一種方法，它區分了戰略設計與戰術設計的，引入了限界上下文與統一語言，提供了實體、值物件、聚合、工廠、資源庫等。同時，業界也有很多DDD的相關著作，可以幫助我們更有效地去理解這些概念與具體應用方法。當然，你本身所在的領域與你的過往經驗，也是應用這些方法時非常值得參考的。

軟體的架構，究其根本是物理世界在數字世界的對映。在DDD的應用中，我們不僅汲取DDD的思想與方法，也學習敏捷、DevOps、測試、微服務等領域知識，同時結合我們既往的經驗，逐步總結和迭代了適合我們的一套架構設計體系與方法。正如Eric Evans所說的，“DDD還未結束”，我們也在持續實踐與持續調整。

本文是基於筆者當前的認知與理解所形成的，歡迎留言討論。

本文由豬齒魚技術團隊原創，轉載請註明出處：豬齒魚官網

關於豬齒魚

豬齒魚Choerodon數智化效能平臺，提供體系化方法論和協作、測試、DevOps及容器工具，幫助企業拉通需求、設計、開發、部署、測試和運營流程，一站式提高管理效率和質量。從團隊協同到DevOps工具鏈、從平臺工具到體系化方法論，豬齒魚全面滿足協同管理與工程效率需求，貫穿端到端全流程，助力團隊效能更快更強更穩定，幫助企業推動數智化轉型升級。戳此處試用豬齒魚