此前,在由 ThoughtWorks 舉辦的領域驅動設計峰會 DDD-China 2019 上,InfoQ 記者就開發團隊為何需要 DDD、目前業界實踐 DDD 的挑戰等問題對中興通訊資深軟體架構師張曉龍進行了採訪。以下為重點內容,這裡記錄採訪內容的學習筆記。

  張曉龍認為,開發團隊真的需要 DDD。DDD 思想貫穿了整個軟體開發的生命週期,包括對需求的分析、建模、架構、設計,和最終的程式碼實現,甚至對程式碼的測試與重構。程式碼是業務的核心資產,開發團隊肯定是程式碼的編寫者和守護者。

  對於開發團隊而言,需要關注以下幾點:

  第一,統一語言,讓團隊成員可以做到無障礙溝通,不管是什麼角色都能基於同樣的畫面進行討論;

  第二,團隊中各個角色都圍繞領域模型開展工作;

  第三,程式碼物理分層設計標準化,比如說在分層設計時,基礎設施層怎麼設計,應用層怎麼設計,DTO 應該放在哪兒,領域層中各個建模元素如何組織?

  更進一步,在分層架構中,應用層更加關注橫切面的東西,比如上報告警、給使用者傳送 Email 等,這些最好都集中放到應用層裡面。但觸發是在領域層發生的,應用層怎麼知道?可以通過領域事件來實現依賴反轉,即應用層訂閱領域事件,領域層釋出領域事件。

  在中興通訊,核心業務屬於通訊行業,DDD 的應用場景跟網際網路企業有著很大差別,中興通訊的技術與業務兼具複雜性,其軟體規模大,功能複雜,特性交叉,還有高質量、高效能、高可靠的要求。

  第一,領域專家下團隊,和團隊一起交流和協作;

  第二,教練指導,開展戰訓營,定期 review;

  第三,在架構、設計、編碼和工程實踐方面,不僅採用 DCI、DSL、正交設計、組合式設計,還要遵守編碼規範和紀律,運用嵌入式 C/C++ 最佳實踐,此外還要保證有持續交付的流水線和每日 Code Review。

DDD 的困局

  最近幾年 DDD 的火爆也給業界開發團隊帶來了一些迷思,比如,為什麼我的 DDD 推行不下去?為什麼我的 DDD 做起來總是跟敏捷一樣,最後都變了味?

  張曉龍總結了 DDD 目前面臨的幾大困局:

  第一,領域案例面比較窄。目前業界的 DDD 實踐案例並不多,而且很多案例是偏向網際網路領域的,對於工業領域、嵌入式領域和作業系統領域基本沒有涉及;

  第二,DDD 書籍非常少,而且大多數書籍是以 Java 或 C# 寫的。如果開發團隊用的是 C、C++、Python 或 Go 語言,基本沒有可參考的書籍,難度也就更大一些(尤其是 C 和 C++);

  第三,各個巨頭公司,比如谷歌、微軟、BAT 等,很少組織、參與或贊助 DDD 峰會,沒有形成引導作用,業界自然也就少有跟隨效應;

  第四,開發團隊要麼找不到領域專家,要麼領域專家無法與開發團隊長時間保持溝通,導致實踐中出現偏差;

  第五,DDD 落地有一定的門檻,對開發者的技能和素質都有較高的要求。

  針對以上幾大困局,張曉龍也給出了自己的解決方案:

  • 培訓 OOA、OOD 和 OOP 的基本知識,並實戰演練,不斷彌補與高手的差距 ;
  • 領域專家和團隊一起工作,確保大家頭腦中的畫面是一致的;
  • DDD 建模要有文件交付物,並和程式碼同步演進,以便不熟悉程式碼的人員也能看到並理解領域驅動設計成果的全貌。

  軟體開發沒有銀彈,DDD 也不是萬能的。如果開發團隊真的決定用 DDD 的思想指導軟體開發,就一定要跟隨時代的腳步,吃透 DDD 這個舊瓶裡裝的新酒。

&n