文章簡介
在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還未結束”，我們也在持續實踐與持續調整，
本文是基于筆者當前的認知與理解所形成的，歡迎留言討論，
本文由豬齒魚技術團隊原創，轉載請注明出處
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/374393.html
標籤：其他