【軟體工程老方法為何能解微服務新難題？】10個QA快速認識DDD

微服務（Microservice）架構是近幾年最紅的應用程式架構，隨著Web技術、雲端架構、容器技術、DevOps流程等新興開發技術和方法的成熟和普及，將傳統大型單體式應用（Monolithic），拆解、重構成鬆耦合的微服務架構，成為更容易更新、快速發布、彈性擴充的雲端原生應用，不只網路公司必用，更是現在企業IT現代化的新主流作法。

最知名的微服務實例之一，就是 Uber用了約2,200個關鍵微服務，才打造出支援全球超過700個城市，數千萬名代雇駕駛，每天上千萬趟行程的服務架構。Uber的微服務架構圖就像是一張密密麻麻的網狀星雲圖，呈現出數千個微服務相互關連後的複雜性。

複雜性就是微服務的價值和考驗。微服務顆粒度越小（程式越小），就越容易針對單點爆量需求來擴充，功能異動的影響範圍也越小，派送、部署的速度也能越快，但是，代價是顆粒度越小，微服務的數量就得越多，應用架構複雜性也越高，維運和管理的困難度都會跟著提高。

如何拿捏「適當的顆粒度和架構」成了微服務設計時的關鍵，也是最大的難題，可是，這個問題，一直沒有標準答案，而且沒有永遠的答案，甚至10個架構師重構同一個應用，會有10套微服務架構。

早在2003年就問世的軟體開發方法Domain-Driven Design（領域驅動設計，簡稱DDD），提供了一套可以系統性拆解微服務的方法論，也因此再度爆紅，成了不少網路公司、企業用來解決微服務設計難題的新方法。

例如星巴克早從2015年推出的獎勵忠誠度計畫（Loyalty Program），隔年決定重新設計改版的新一代獎勵平臺，就是採用了DDD來設計，才打造出一個有能力處理十億個事件的事件來源引擎，每秒API交易次數達到數千次以上。

臺灣DDD社群核心成員整理了一份QA，可以快速認識這個老方法，一窺為何DDD能成為解決當紅微服務架構難題的新解方。

 Q1：為何微服務當道，DDD重新受到重視？ 

 A  約2013、2014 年間，全球開始興起一波將老舊系統轉型為微服務的話題，當時 《建構微服務》（Building Microservices） 一書的作者 Sam Newman 更在書中開宗明義指出，微服務的設計是一連串現代軟體工程的大成，涵蓋了領域驅動設計、持續交付、按需求虛擬化技術（On-Demand Virtualization）、基礎架構自動化、小型自主團隊（Small Autonomous Team）、大規模系統部署。這些元素都有助於微服務建構和實踐時的參考。

然而，多數人最關鍵的問題在於，試圖將老舊系統拆解成微服務時，每個人對於拆解方式與系統邊界的理解和定義，可能不一致。拆多了，要面臨過度龐大分散式系統的系統通訊與監控的困難。拆得太少，又顯得單一服務的職責太重、太雜，導致每次要修改部分功能，就得重新部署這支單一服務，受影響的範圍過大。

在多種不同的微服務切割方法中，可以回歸軟體建模的根本面，場景驅動的業務表述，大部分商務應用軟體，都循著一系列的應用場景描述開始捕捉，進而分門別類地，收歸其職責畫分到不同的模組底下，對應到分散式系統的開發部署角度上。開發者經常會發現，若能夠從業務場景梳理不同服務與模組之間的關係，能夠較為「有效」地管理跨服務之間溝通的複雜度與頻率，也容易掌握服務與服務之間的上下游關係，進而能指導團隊協作與組織間的協調。DDD是一種在軟體開發生命周期前期，就能投入的系統建構指引，也因此，2003年就出生的 DDD，在2015年後再次重生，閃耀在各大產業面前。

 Q2：DDD、敏捷和DevOps三者有何不同？ 

 A  這三者完全不同，但彼此能夠恰好地補足互相的不足。

簡單來說，敏捷（Agile）是一種軟體開發流程的方法，DDD是一種軟體分析設計的方法，而DevOps則是開發團隊和維運團隊彼此為對方多想一點的文化。（國泰金控數數發中心雲端技術架構師顏勝豪的觀點。）

但是，有些企業導入敏捷時，會遇到企畫端執行敏捷，但需求落地仍然按照既有IT開發流程，導致系統無法快速迭代，細究根因除了敏捷團隊缺乏開發人員以外，也有系統架構耦合性過高、整體開發周期過長等問題。

身兼敏捷及DDD顧問的香港IT顧問Steven Mak對臺灣社群分享時也提到，敏捷的導入，除了價值觀和團隊的建立外，系統架構和軟體開發也是很重要的一環。ThoughtWorks首席科學家，也是《重構》一書作者Martin Fowler曾在演講中指出，現今敏捷遇到的問題之一是，缺乏對技術專業重要性的重視。這些技術專業涉及了打造一個架構整潔、易於維護、品質優良的系統，或是關於如何建置一套高效穩定的開發部署流程，來縮短需求提出到上線的時間，來提升價值交付的速度，但要如何做到，敏捷無法告訴我們。

開發團隊要抉擇，做出「可以動就好的軟體」還是一個「能夠適應改變的軟體」？業務單位要抉擇，打造短期亮點的資訊系統「專案（Project）」，還是一個長期發展的資訊系統「產品（Product）」。

如果答案是後者，DDD、Agile及DevOps的融合，能夠提供一個好的方向，打造出珍視合作互動及軟體工藝、並能持續交付價值的敏捷團隊。

 Q3：國外有哪些DDD知名案例？ 

 A  早在2015年推出獎勵忠誠度計畫的星巴克，在2016年時決定重新設計新版獎勵平臺時，就採用了DDD，打造出一個有能力處理十億個事件的事件來源引擎。英國衛報十多年前的網站改版，就花了2年用DDD重新設計過一次。SalesForce 也曾以 DDD 來面對超過兩萬五千個開發者協同的複雜問題。

 Q4：臺灣有哪些DDD實例？ 

 A  臺灣已有一些早期先行者，試圖在各行各業中實踐。像是 KKDay在 2019年就試圖引入DDD 與事件風暴工作坊 ，來加強業務團隊與技術人員協作時的共同理解。大型企業如國泰世華銀行、中國信託銀行，都分別在 2020年開始投入更多實踐，大家的目標都是在既有系統能因應快速創新的需求下，能將既有資產、系統更好地梳理業務流程，重整出高內聚、低耦合的一套有彈性的軟體，希望未來有機會可以共用這些重新設計過後的系統。為此，越是大型複雜的應用場景中，DDD 幾乎成了現代改造系統架構的首選。

 Q5：想了解DDD最新趨勢，要追蹤那些意見領袖？ 

 A  領域驅動設計之父Eric Evans、中國領域驅動設計傳教士張逸、中國領域驅動設計社群組織者王威、創辦Virtual DDD也是領域驅動設計顧問的Kenny Baas-Schwegler、《領域驅動設計樣式、原理與實踐》共同作者Nick Tune、Event Storming發明人Alberto Brandolini、以及《實現領域驅動設計》作者Vaughn Vernon。

 Q6：上手DDD的第一本書？ 

 A  實現領域驅動設計》(Implementing Domain-Driven Design, IDDD)和《領域驅動設計樣式、原理與實踐》 (Patterns, Principles, and Practices of Domain-Driven Design)。

另有一本《DDD 15年》，這是由23位領域驅動設計專家所共同著作。每一位作者各自撰寫一篇文章，傾注了他們對於領域驅動設計的知識和實務的理解。由於每一位專家的背景和專注的專業領域不同，因此提供了運用領域驅動設計的豐富角度，例如像是從物件導向、函數式來運用DDD，內容非常全面。讀完後可以感受到「原來領域驅動設計還能夠這樣運用！」。本書有多國翻譯版本， DDD TW社群也著手翻譯這本書，近期將以正體中文發行。

 Q7：推薦那些DDD學習資源？ 

 A  有不少Youtube影音頻道可以參考，如包括了Virtual DDD頻道、Domain-Driven Design Europe頻道、Vaughn Vernon頻道、Explore DDD頻道、KanDDDinsky頻道、Domain-Driven Design Barcelona頻道和Domain-Driven Design London，另外也推薦加入DDD TW 臉書粉專和Youtube頻道。另外，DDD TW社群志工fx777，在2019年iT邦幫忙鐵人賽中優選得獎作品「Think in Domain-Driven Design 系列」，以30篇文章詳細介紹DDD和事件風暴的進行方式。

 Q8：企業IT要了解DDD，如何上手？ 

 A  可以加入DDD TW社群，社群提供了許多領域驅動設計的學習資源，可以避免企業在學習過程中的障礙。DDD TW社群會定期與中國和歐美各領域驅動社群或團體交流，來掌握領域驅動設計的理解及新資訊。

 Q9：業務團隊要了解DDD，如何上手？ 

 A  可以先從工作坊，包括Event Storming或Domain StoryTelling著手，先感受領域驅動設計帶來的好處。接著開始著手研讀領域驅動設計戰略部分的資訊，並且內化和整合到自己的業務知識，來理解到如何更好地將自身業務知識傳遞給團隊，來降低溝通成本提高協作效率。

 Q10：臺灣DDD社群目前規模？可提供什麼幫助？ 

 A  這是一個由臺灣軟體現役從業人員所經營的非營利社群，在2021年1月已經達到2,624人。社群將藉由多種不同類型的活動，將領域驅動設計的概念及實務和參與活動的朋友們分享與交流。DDDTW常規活動，有月例會、讀書會和年會。

DDD臺灣社群閃電崛起，接軌全球社群引進跨國開發實務

圖片來源-DDD TW

在2018年底，一個下著大雨的夜晚。DDD TW社群發起人高翊凱和張國昭，在巷口小七超商的一段討論後，花了2年，催生出一個核心志工團隊16人，社群規模超過2,600人的軟體開發社群。

高翊凱和張國昭好幾年來，一直很想在臺灣推廣領域驅動設計，甚至在自身任職公司都嘗試引入實踐，但擴散效益仍舊緩慢。2017年張國昭還自費到北京參加首次DDD中國社群年會，親身感受到海外社群的熱情。2018年夏天，2人決定展開行動，先在臉書成立社群粉專，但是，半年下來仍只有百來人規模。

兩人再次飛往中國參加第二屆峰會，結識了中國社群關鍵組織者王威和張逸，他們都是在中國軟體領域的實踐家和意見領袖，也成了臺灣社群發展跨區域協作的契機。所以，高翊凱和張國昭在下雨那夜訂出5大發展願景，擴大社群觸及人數、組織線下讀書會、透過MeetUp挖掘臺灣專家來交流、接觸全球DDD領域最大社群DDD Europe建立連結、培養社群新血和核心志工。

有了更明確的目標，2019年DDD臺灣社群開始快速發展，那一年就辦了超過20場的線下讀書會和Meetup活動，社群規模首度超過了1千人，透過讀書會也逐漸組成了核心志工團隊。還在年底舉辦了一個連續數周的微服務黑客松開發競賽，也獲得廠商贊助。

中國DDD社群看到了臺灣DDD社群快速崛起，在2019年底的峰會直接邀請高翊凱和張國昭登臺分享，張國昭的演講還獲選為最受歡迎的主題。不只在中國，高翊凱也積極將臺灣社群經驗發布到DDD Europe社群中，因此而結識了歐洲社群的主要組織者，打開了與全球社群協作的管道。

2020年疫情讓遠距協作成為主流，DDD Europe因此成立了一個全球性虛擬DDD社群，更在2020年5月，舉辦了一場24小時馬拉松的全球線上大會，臺灣DDD社群是歐美以外，唯一一個受邀的在地社群。高翊凱和張國昭被安排在第一組講者，後面緊接著登場講者是DDD之父Eric Evans、《實現領域驅動設計》作者Vaughn Vernon和Event Storming發明人Alberto Brandolini等當代一線軟體顧問大師。從此，臺灣的DDD TW社群正式與DDD Europe社群搭上線，多位歐洲DDD專家更在2020年底遠距參與臺灣年會，分享最新DDD經驗。

2020年11月底，舉辦了一連兩天的首屆臺灣領域驅動設計年會，涵蓋了產品、流程、設計三大議題，講者除了來自中國、英國、荷蘭等地社群之外，也有臺灣老、中、青三代的講者。參加者超過330人，3成來自金融業，多家金控也派員參加。除了企業高階主管、IT與研發、也有來自業務、行銷端的從業人員。第二天活動一口氣舉辦了6場工作坊，超過120人參加，最搶手的就是事件風暴工作坊，還得額外加課。

DDD TW社群每個月會找來業界有領域驅動設計實務經驗的第一線專家分享實踐經驗，不只技術，還包含團隊協作與業務分析。對於領域驅動設計經典書籍的讀書會持續進行，未來計畫細分為初階與進階兩個等級。透過DDD Europe社群聯繫，臺灣DDD TW社群也正將2019年在歐洲大賣的新書《DDD 15 Years》（中譯《DDD 十五週年》），透過社群志工力量，翻譯成正體中文版，預定2021年上半年發行。