DDD峰會歸來話DDD

一場大戲落幕，首屆DDD中國峰會如大會主題色一般的紅。或許在12月9日這一天，全中國的DDD粉絲大約有一半都匯聚在了國家會議中心。聽起來是幸，其實是不幸，因為DDD在中國的人群基數實在是太少了。

因為要負責大會的其中一個Track，期間又要接受採訪，另外還有朋友到訪，所以除了前面的兩個keynote以及我自己的session（這是當然的），我沒有完整聽完一個session。然而單單是和DDD大咖、專家與愛好者們交談，已經受益匪淺了。參會歸來，關於DDD的idea產生了許多，我覺得有必要和DDD談談我的想法。

DDD是什麼

正如Alberto在keynote中提到，DDD不是架構。我贊同這一觀點，並一直認為DDD是一種方法論（Methodology）。根據維基百科：Methodology is the systematic, theoretical analysis of the methods applied to a field of study，DDD正是針對軟體領域提供的系統與理論分析方法。Eric在創造性地提出DDD時，實則是針對當時項目中聚焦在Data（主要是DB Schema）為核心的系統建模方法的批判。這種面向數據的建模方式無法應對日漸複雜的業務邏輯，也無法更好地應用當時正沸沸揚揚的OO設計思想。這是設計觀念的轉變，蘊含了全新的設計思想、設計原則與設計過程。

坦白說，Eric Evans的DDD奠基之作《Domain-Driven Design》並沒有非常清晰的系統脈絡，戰略設計與戰術設計也未成體系。Eric創造了一堆新奇的概念，隱隱中確乎有一條圍繞“領域”進行設計的思想主線，但對整個設計過程的描述卻是不清晰的。結構上，我更認同Vaughn Vernon一書《Implementing Domain-Driven Design》，該書清晰地給出了從戰略設計到戰術設計的設計過程。

我在和ThoughtWorks的餘丹妮聊到DDD時，我吐槽說Eric的DDD其實沒有解決三個問題：

• 如何進行領域建模
• 如何識別Bounded Context
• 如何在戰術層面尋找對象

餘丹妮則認為DDD不是架構（設計）方法，因此不能把每個設計細節具象化。DDD是一套體系，這就決定了它必須具有開放性，在這個體系中你可以用任何一種方法來解決這些問題。我深表贊成，卻也認為這些關鍵問題如果沒有具體落地的方法，可能會讓團隊無可適從。這其實也是DDD在許多項目中難以推行的部分原因。

EDD

Alberto是EventStorming的創始人，他在keynot中強調建模應該專註於event。EventStorming方法貫穿了DDD整個設計過程，包括Ubiquitous Language、Bounded Context等戰略設計的元素，也能沉入戰術設計中，以Event作為主要的設計驅動力。

在聆聽Alberto的演講時，我突然想到這種以領域事件作為設計驅動力的思想會否走出另一條不同的路（分支）。我之前在《或許是領域建模的真相》中模糊提到這樣的思想，例如針對事件建模，實則是對業務流程以“狀態機”形式進行建模。狀態的遷移，就是command或者decision對event的觸發。

如果我們再將event視為一種不可變、可追溯的消息，那麼DDD社區提出的許多知識都可以圍繞著event進行設計，包括：

• EventStorming
• Event Sourcing
• CQRS

考慮event的不變性與消息的本質，我們還可以將如下內容引入：

• Functional Programming
• Reactive Programming

那麼我們是否可以提出Event Driven Design的設計概念呢？與EDA（Event Driven Architecture）不同，EDD算是DDD的一種分支，是一種設計方法學，涵蓋了戰略設計與戰術設計等多個層次。而它與傳統DDD的區別在於建模思想與編程泛型的不同。

微服務拯救DDD

我說“微服務拯救了DDD”，其實是對肖然說的一句戲言，並不准確。在諸多社區力量的貢獻中，DDD一直都在生長，在DDD提出來的十五個年頭，不僅沒有走入老年期的落寞，反而在每年都生長出不同的嫩綠新葉。既然DDD沒有衰亡，何談拯救？然而，不可否認的是因為微服務的火熱，讓DDD這種緩慢生長的態勢突然煥發了勃勃的生機，就好像給這棵大樹註入了生長劑一般，一下子開枝散葉。凡微服務所及之處，皆可見DDD的身影。這就造成了微服務拯救DDD的錯覺。

我在演講《Bounded Context的實踐意義》中提及了六邊形、限界上下文與微服務之間的關係，這裡不再贅述。但肖然的《為不確定性架構》演講提及了微服務保證了系統的simplicity，卻讓我浮想聯翩。

對於架構，我一直強調對系統複雜性的應對。我曾經在十月份的一個會議上分享過《如何應對架構的高複雜度》，內容其實來源於我對複雜系統思考所撰寫的一篇文章。我從理解力與預測能力兩個角度剖析軟體系統的複雜度。這個思考角度實際來自Jurgen Appelo對複雜系統理論的闡釋。Jurgen Appelo將Complicated與Complex分別放在理解力與預測能力兩個迥然不同的維度。Complicated與Simple（簡單）相對，意指非常難以理解，而Complex則介於Ordered（有序的）與Chaotic（混沌的）之間，認為在某種程度上可以預測，但會有很多出乎意料的事情發生。如下圖所示：

系統的規模與結構會幹擾我們對系統的理解，而需求的變化則是我們無法預測的。那麼，微服務是怎麼應對系統複雜度的呢？核心思想是“分而治之”，它從系統規模著手，將一個大的系統拆分為一個個細粒度的服務。即使不考慮拆分的合理性，我們也可以看到它雖然控制了規模帶來的複雜度，卻加強了結構的複雜性。

個人認為，微服務對simplicity的保證，實則是將業務複雜度轉移到了技術複雜度。顯而易見，每個微服務的業務是非常簡單的，代碼易於理解和維護，也可以非常容易地進化乃至於替換。當我們需要開發和維護多個微服務時，如何管理和監控服務，如何梳理服務之間的通信，如何保證數據的一致性（最終一致性），都來自技術層面的挑戰。

這種複雜度的轉移為何能得到多數人的認同？針對IT人員，它其實基於兩個前提：

• 業務是不可控的，技術卻相對可控：相對於技術，業務對變化更加敏感，我們也無法正確地預測業務的變化
• 技術的複雜性可以通過分工來解決：多數應用開發公司可以重用微服務的平臺、框架或工具，然後集中精力來對付業務；降低了業務複雜度，就等同於降低了整個系統的複雜度

DDD的未來

在接受會議主辦方的採訪時，希望我能給DDD打call。那麼DDD重要嗎？非常重要，但它確實不是“銀彈”。正如前面所述，DDD其實一直在生長。由於沒有任何一家商業化公司推動DDD，它反而沒有受到利益關係的干擾，雖然生長緩慢，但卻健康。DDD以“領域”為核心，只要軟體系統仍然還在處理“領域”，理論上DDD就有其生存的空間。如果我們不把DDD具象化（正如前面所說），它就可以成為一個不錯的“框”，凡是和“領域”相關的理論、方法、實踐與模式，都可以往這個框里塞。

倘若能一直保持DDD的開放性，保持DDD的獨立性，我覺得在未來的五年乃至十年，DDD仍將煥發生命力，只是它的面貌會更加多姿多彩，甚至超過Eric Evans對DDD的原初定義。畢竟，軟體系統的核心只有兩個：領域和演算法。也許，只有到了AI演算法能把領域開發的職責都能攬過去，DDD才不會存在了，因為那時候已經沒有了領域，只剩下了演算法。