2020年12月19日，第四屆領域驅動設計峰會（DDD Conference）再度開啟。不同於往屆的線下舉行形式，本屆峰會採取線上的形式，致力於打造一場架構設計和技術實踐的盛宴。作為軟體架構設計新的潮流，領域驅動設計（Domain Driven Design，簡稱DDD）強調業務和技術的統一性，為複雜領域軟體工程的設計決策提供實踐框架，幫助企業不斷拓展數位化業務。
2020年，一場突如其來的全球公共衛生事件對於人們的生活與工作產生了巨大的影響，各行各業積極應對挑戰。業務的劇變對架構平臺帶來了巨大的衝擊，如何客觀地評估分析架構現狀、該從哪些維度設定架構演進的目標，又如何引導架構增量地向目標演進，成為當下企業持續探索的命題之一。
領域驅動設計峰會（DDD Conference）是由國內領域驅動設計（DDD）思想和實踐的領軍者——ThoughtWorks的架構諮詢師們組織發起，希望為國內的領域驅動設計（DDD）實踐者們提供一個互相交流、分享自己團隊的成功經驗的平臺，使得領域驅動設計（DDD）的架構思想能夠在國內被更多人所認知，從而形成更大的規模效應。
六大主題分享全景呈現DDD新常態
本屆峰會邀請了ThoughtWorks全球技術總監及軟體架構師Neal Ford、Unisys首席應用架構師與全球DDD社區領袖Indu Alagarsamy等來自海外的領域驅動設計（DDD）的領軍人物分享在架構設計領域出現的新的嘗試和探索。
同時，民航信息技術總監張逸、IBM資深應用架構師於靜、《中臺架構與實現：基於DDD和微服務》作者歐創新等國內持續實踐領域驅動設計（DDD）的代表和思想領袖也分享了他們在各個不同場景下對於使用領域驅動設計的感悟和總結，展現了在後疫情時代領域驅動設計將會出現的新變化。
不論是演講嘉賓還是話題設置，本次峰會既呈現了DDD的現狀與未來趨勢，又展示了DDD的最佳行業實踐，全方位呈現了DDD的發展情況。
構建演進式架構
在過去十年中，DDD的限界上下文概念影響了軟體架構，並啟發Neal Ford產生了《演進式架構》書中的一些思想。作為ThoughtWorks全球技術總監及軟體架構師，Neal Ford是國際公認的軟體開發和交付方面的專家，尤其是在敏捷工程技術和軟體體系結構的交集方面，以及DDD如何啟發他產生了軟體架構的量子概念。
業務實踐在變，工具和框架在演進，創新的工具和技術不斷湧現，這讓軟體開發生態體系也是瞬息萬變。在過去的幾年裡，軟體開發核心工程實踐的漸進發展，讓開發者重新思考架構是如何隨著時間的推移而變化的，以及重要的架構特徵如何能夠在架構演進過程中得到有效保護，這促使Neal Ford與ThoughtWorks全球CTO Rebecca Parson博士一起總結提煉了演進式架構的核心概念。
在峰會的主題分享上，Neal Ford討論了有關可演進架構的兩個關鍵洞察。Neal Ford指出，演進式架構是在當需求出現的時候通過適應函數來把握架構演進的方向，演進式架構隨著系統和業務的增加而變化，而且能夠保證用戶得到想要的部分，追求性能上的優化，追求擴展性的不斷提升。
演進式架構支持跨多個維度的引導性增量更改。演進架構從進化計算世界借鑑了適應度函數的概念，以定義所謂的架構適應性功能。這是對某些架構特性或架構特性組合提供客觀完整性評估的一種機制，描述了一系列可用於驗證體系結構適用性的工具。
Neal Ford表示，原子適應度功能是僅關注單個特徵和體系結構的功能，而整體適應性功能則關注特徵的組合，很多時候體系結構特徵相互糾纏。一旦定義了這些架構適應性功能，企業需要持續集成、部署管道以及諸如此類的敏捷調整實踐的領域。
演進式架構最初目的是研究適應度函數的可演進性，在此過程中，我們希望能夠衡量特定架構風格的演進程度，雖然產生了許多代碼級量度，但是這還不夠。受到DDD的啟發，Neal Ford提出了軟體架構的量子概念。
架構量子是一種以軟體架構表示的領域驅動設計中的有限上下文的想法。架構量子具有高功能凝聚力和同步通信的獨立可部署組件。架構量子關注事物如何耦合在一起，不僅分析了架構，而且還分析了操作級別，並包含了資料庫和用戶界面等內容。
「架構量子對有限上下文的定義會有所不同，因為我們正試圖衡量事物在生態系統中的耦合程度。我們確實想要一個有界上下文的概念，但要用架構術語來表達。我們希望它作為一個有用的架構分析工具。」Neal Ford說。
領域驅動設計和消息傳遞的融合
DDD不僅可以幫助企業敏捷地編寫高質量的代碼，還能使所編寫的軟體能靈活應對業務變化。當使用消息傳遞技術在清晰整潔和定義良好的限界上下文之間進行通信時，就可以消除時序上的耦合，結合DDD就能構建可以自治的微服務。
Unisys首席應用架構師、全球DDD社區領袖Indu Alagarsamy在分享中認為，DDD與作為軟體技術的消息傳遞進行融合，也就是實現領域驅動設計與事件驅動架構相結合，構建可以隨著業務變化而擴展的可靠系統。
Indu Alagarsamy還以電商場景進行了詳細說明，銷售、庫存、運輸等不同部門的員工使用的領域語言不同，領域驅動設計引入了限界上下文的概念。我們可以根據團隊或部門拆分模型，進行上下文的劃分和設計。這時上下文之間需要能夠以一種自主且可靠的方式進行通信，這是事件驅動架構很好地與領域驅動設計結合的地方。
命令和事件都是消息，但是通過明確區分什麼是命令、什麼是事件，可以幫助我們更好地設計軟體。然而如何設計一個具有事件、消息和命令的系統呢？這就需要引入事件風暴。事件風暴是一種了解業務流程的協作可視化方式，在討論流程中的業務行為時，使用事件風暴，程式設計師和架構師能夠找出信息流。
「我們要做的是編寫符合業務需求的正確軟體，了解重要的業務行為有助於編寫正確的代碼，並使軟體與業務保持一致，事件和消息驅動架構可以幫助我們擺脫時間耦合，使軟體組件具有自主性。隨著對領域相關信息的了解越來越多，你可以不斷的改進模型，使其變的更好。如果你想使模型中的上下文自治，可以使用事件在這些不同的限界上下文之間進行通信。」Indu Alagarsamy說。
同時，Indu Alagarsamy認為，微服務的本質在於服務需要自治，並可以根據數據做出決定，不需要不停地詢問其他上下文。因此，事件作為在相同的限界上下文中進行通信的機制，變得非常重要。
領域驅動設計大揭秘
作為《解構領域驅動設計》作者，同時也是民航信息技術總監，張逸對於DDD有著自己的獨特看法，比如數據驅動與領域驅動、領域驅動設計下的單體架構等。
張逸在主題分享中表示，數據驅動進入架構設計領域造成模型沒有上下文的邊界，而DDD引入了限界上下文，通過業務能力完成重用，進而確定領域模型的知識語境，讓架構順應業務的變化方向。
DDD的特點與價值在於它定義的模式，限界上下文與聚合是DDD的核心模式。限界上下文是架構層次的自治單元，是業務能力的重用而非模型的重用。而微服務的協作就是限界上下文的協作，領域驅動設計成為顯學，進入黃金時代。
單體架構（Monolithic Architecture）是一種將所有功能打包在一個容器中運行的設計風格，一個實例中集成了一個系統的所有功能。從中大型項目的業務形態、複雜度及響應速度等維度看單體架構時可以發現它存在擴展性差、無法實現複雜業務、技術升級困難、開發效率低等問題。
張逸表示，常見的區分單體架構和微服務架構的做法並不正確，雖然沒有限界上下文的單體架構可能導致「大泥球」，但是單體架構也要通過業務能力進行縱向切分。如果單體架構通過限界上下文進行邊界控制，其實可以降低微服務架構風格的演化成本，也能規避過度微服務化帶來的技術風險。
另外，張逸認為，領域驅動設計存在四大「天生不足」，比如領域驅動設計缺乏一個規範的過程指導，使得其缺乏可操作性；領域驅動設計沒有匹配的需求管理體系等，為此，我們需要領域驅動設計統一過程，確保DDD的落地實施。
領域驅動設計在大型遺留系統改造中的實踐
自領域驅動設計和微服務概念提出至今，越來越多的網際網路巨頭以及傳統行業都開始對自己的遺留系統進行微服務改造，通過把系統拆分為更加靈活、有業務邊界上下文、鬆耦合的服務來應對快速變化的市場。
IBM資深應用架構師於靜在主題演講中介紹了一個有著二十年歷史並支撐百萬交易額的電商平臺如何通過DDD方法華麗轉身的實踐，從這個案例我們了解到遺留系統進行DDD改造過程中的點滴經驗。
於靜表示，為了加速數位化轉型與業務模式創新實現，遺留系統的改造會面臨很多難題，比如交付速度慢、應用架構不滿足快速迭代需求、技術受限、維護成本高、業務流程複雜等。而在改造過程中，現有業務不能停，同時過程難控制、結果難驗證等問題也非常突出。
為此，遺留系統改造實施需要確立目標與制定策略、業務梳理、服務改造、集成遷移測試、反饋。在DDD指導下，企業需要通過事件風暴對業務討論，審視現有的業務邏輯，逐步用新應用程式和服務替換特定功能段，增量遷移舊系統。隨著舊系統功能的更換，新系統最終取代了所有舊系統功能。
於靜說，企業在遺留系統改造中應該遵循「先鋒隊、樹立模範、大部隊」的階段性原則。具體來說，「先鋒隊」階段是挑選規模較小、功能簡單，業務較為獨立的功能模塊進行改造，隨著老系統的功能越來越多的被微服務系統所代替，老系統也最終被替代。需要注意的是，當發生新老系統的功能切換時，應該逐步切換用戶流量，對用戶儘量透明，使得改造過程過渡平滑。
當中臺遇上DDD，如何設計微服務？
當前，中臺、微服務是業界關注的熱點話題。如果將兩者放到DDD的背景下，如何建立DDD、中臺和微服務的統一語言？如何將三者融合完成協同設計？《中臺架構與實現：基於DDD和微服務》作者、極客時間《DDD實戰課》專欄作者歐創新在主題分享中回答了這些問題。
歐創新表示，從企業架構角度來講，業務中臺屬於業務架構的範疇，業務中臺重構的過程本質是基於復用目的的企業級業務架構重構。在業務量不大的時候，我們用傳統的集中式架構就可以解決複雜問題。而當面對海量網際網路業務比如雙十一，企業原來的架構就不足以解決業務和應用的擴展性問題，因此我們需要將原來大的問題域拆小，將單體應用拆分為微服務，進而上雲。所以，DDD和微服務都是解決複雜問題的設計思想。
在DDD概念裡，如果只從業務架構角度分析的話，中臺本質上是從領域到更細的子域劃分過程中的一個橋梁，只從業務領域角度分析，它可能對應DDD領域中的某一個核心子域或通用子域。
對於DDD與中臺和微服務的關係，歐創新認為，中臺本質是領域中的某一個子域，需要抽象並標準化，按照單一職責原則建立可復用的領域模型。微服務是中臺最佳技術實現。DDD是一種可以同時指導中臺業務建模和微服務設計的方法論，遵循高內聚低耦合的原則，完成從業務端領域建模到應用端微服務實現的無縫落地。
我們看到DDD和中臺設計兩種知識體系的融合需要建立兩者通用語言，團隊通用語言也是DDD不斷強調的內容。一般對於小的項目我們可以直接從問題域開始事件風暴，完成領域建模。而對於企業級中臺而言，業務領域非常大，我們需要做好頂層設計，劃分子域，確定中臺的大致邊界，然後基於這個邊界開展事件風暴，劃分限界上下文，完成領域建模，它是一個自上而下的設計過程。
「DDD博大精深，但DDD也不是萬能的『銀彈』。將中臺和DDD視作一種思維方式和設計思想，結合企業實際情況靈活運用才是王道。」歐創新說。
DDD從戰略設計到代碼落地的三階段方法
ThoughtWorks總監級諮詢師楊雲指導過多個DDD實施項目的落地，在峰會的主題演講上楊雲系統介紹了如何將DDD建模在大規模開發團隊的情況下確實的落地到代碼層面。
為什麼企業覺得DDD落地難？楊雲表示：「首先，因為DDD進入了更深層的應用。DDD從戰略層面的應用進入到戰術落地層面，而不再僅僅停留在子域劃分、微服務劃分等。其次，參與建模的人，從業務專家和架構師級別的技術專家，深入到產品經理、軟體工程師等執行具體事務的人員，面臨在百人以上開發團隊大項目上保證代碼按照模型落地的難度。最後，DDD建模的投入和交付時間點的矛盾、DDD建模投入的即時性和DDD模型收益的長期性之間的矛盾。」
在DDD落地方面，企業需要對戰術級別的建模提供更具體、更模式化的指引。對於大規模項目，設計更明確、與代碼實現直接相關的微觀模型。提供更好的工具降低DDD模型建設和維護成本，提高模型和代碼一致性。
基於此，楊雲提出了DDD落地的三階段方法：事件風暴階段聚焦戰略建模、子域劃分、微服務拆分；名詞動詞階段，在子域或微服務內，細化實體和行為，識別重要角色和重要規則，建立子域內核心概念的結構化模型；類型流階段，微觀展開具體行為，將承載業務邏輯的純函數和依賴基礎設施的副作用函數剝離。
楊雲表示，建模是迭代的，不是線性單向的。DDD建模需要考慮團隊工作的細節層次，採取適當的方法：用事件風暴來做戰略建模、用名詞動詞法做子域內的結構化戰術建模、用類型流做行為內部的微觀詳細設計。
結語
DDD從2003年被提出來以後，得到了業界的高度認可，特別是微服務架構、中臺等逐漸盛行，DDD正在加速在企業業務實踐中的落地。而領域驅動設計峰會為DDD社區提供了一個絕佳的交流與分享平臺，也將極大推動這種進程，更好地促進DDD的發展。