基于領域消息驅動的輕量級Spring—DDD插件設計與實現

摘 要： 領域驅動開發（DDD）是完全基于內存的業務對象建模（In?Memory）方法，而目前的DDD框架不能完全覆蓋系統業務，也不成熟穩定，無法應用于實際項目的開發。在Spring框架的基礎上，實現了一個基于領域消息驅動和內存建模的DDD插件，在不影響目前系統架構的基礎上，讓項目實施完全兼容DDD設計。同時基于JDK和Disruptor并發框架實現的領域事件消息和領域對象緩存模型，有效地降低了系統的解耦關系，并提高了系統的整體性能及效率。

關鍵詞： 領域消息驅動； 內存建模； 領域事件； 領域緩存

中圖分類號： TN911?34； TP319 文獻標識碼： A 文章編號： 1004?373X（2015）24?0062?04

Design and implementation of light?weighted Spring?DDD plug?in driven by

domain message

WANG Wei1， HUANG Qiang2， 3

（1. Department of Electronic Business， Sichuan Finance and Economics Vocational College， Chengdu 610101， China；

2. College of transportation， Southwest Jiaotong University， Chengdu 610031， China；

3. College of Information and Engineering， Sichuan Agricultural University， Ya’an 625014， China）

Abstract： DDD （domain driven development） is entirely memory?based business object modeling （In?Memory） method， but the current DDD framework is not stable enough to cover the system business completely and can not be applied to the development of practical project. On the basis of Spring framework， the DDD plug?in based on domain message driving and memory modeling was realized， in which the implementation of the project is fully compatible with DDD design without affecting the current system architecture. The domain event message and domain object caching model based on JDK and Disruptor concurrency control framework can effectively reduce the decoupling relationship and improve the whole performance and efficiency of the system.

Keywords： domain message?driven； memory modeling； domain event； domain cache

0 引 言

領域建模（Domain Modeling，DM）的初期是基于對象關系映射的ORM（Object Relationship Mapping）技術。ORM通過數據庫與對象的數據映射，初步解決了關系與對象的不匹配問題[1]，使系統設計分析人員能夠采用純粹的對象技術來解決領域問題。但是隨著業務分析的深入，ORM產生的貧血對象模型由于行為能力的缺失，讓系統又從對象模型退化為事務處理過程，與DM理論逐漸背離；隨后為了避免貧血模型的弊端而出現的充血模型，將業務與數據全部合并到領域模型中。在后來的幾年中，有很多框架都在充血模型的理論基礎上進行了大量實踐（如ROR，Grails，Spring Roo等），這些快速開發框架出現的初期在小型項目上應用非常成功。但是隨著業務增長，領域對象會急速膨脹，維護難度會急劇增加，讓系統處于一個不可控的狀態，并且業務和數據的領域整合會讓系統的結構變得模糊不清，給系統帶來另外的壓力，所以這類框架始終沒有能成功地應用到大型項目開發中去。在2004年，著名的軟件工程專家Evans提出了一個全新的領域開發模型Evans DDD[2]。Evans DDD不但彌補了ORM的對象行為缺失和生命周期問題，也通過領域聚合和分解有效地解決了充血模型隨著領域擴大而迅速臃腫的缺陷，為大型系統設計和開發提供了一個合理的解決途徑。但是由于Evans DDD的設計理念比較靈活，依附于業務設計，且始終沒有一個統一的底層技術構架來支持該模型，導致系統開發人員很難將系統分析轉換為編碼，故大大降低了系統的實施效率。同時現有的框架體系基本是以數據庫為核心的分層結構，也為DDD的實踐造成了很大的障礙。一些全新的框架由于不能很好地兼容以前的遺留系統，也很難得到推廣。為此，本文以Java為例，在充分利用目前廣泛使用的Spring開發框架基礎上，提出了一種基于AOP和JDK Concurrent/Disruptor并發框架實現的領域事件消息和領域對象緩存模型，并完成了能夠較好兼容Evans DDD的整套領域驅動開發插件Takia。在多個項目中的實施證明，該插件在保證系統開發效率的前提下，能夠有效匹配基于DDD的設計方案，消息模型使領域對象之間以及領域對象與服務倉儲等組件之間的交互變得更加靈活。配合領域緩存，可以完全消除領域對象對數據庫的依賴，能夠很好地為系統構架師所利用，以權衡系統整體的得失做出全局性的決策，讓系統的綜合性能達到最高，為基于DDD的項目分析和實施提供有效的架構指導。

1 基于消息的輕量級Spring?DDD領域插件模型

Takia構架設計

本文提出的異步領域消息模型能夠更好地適應領域對象的作用關系和領域擴張問題，更好地支持領域建模。Takia以領域的四要素為基礎[3]，采用分布式緩存系統實現了領域的In?Memory模型，并提出基于異步消息的數據通信方式，優化了領域對象的生產和存儲性能，很大程度提高領域對象之間的解耦程度，以及領域對象的高并發數據處理能力，其整體構架如圖1所示[ 4?6]。

從圖1中可以看出，該構架底層基于Spring業務框架，Hibernate ORM框架和數據庫管理系統，對于常規模型的開發人員來說相對比較熟悉，能夠較容易地完成開發過渡，而Takia插件構架于Spring業務框架之上用以提供領域建模支持。在系統設計時，業務模塊在被劃分成多個領域進行分散式并行開發，一個領域一般由領域對象（Domain Object）、值對象（Value Object）、服務（Usecase Service）和倉儲（Repository）等組件構成[7]；領域的外圍是Takia提供的透明緩存和消息服務，這些服務通過基于Annotation的領域模型配置，使用AOP方式注入到相關的領域對象中，緩存用于提升領域對象的性能，消息用于降低系統及模塊之間的直接耦合。Takia在設計時支持多種緩存實現，默認為EhCache以支持集群和云結構。

圖1 Takia DDD的總體構架模型

2 Takia的消息模型設計

并發的事件驅動模式是Takia的重要特點。通過DomainMessage作為橋梁來實現領域組件之間的信息交互，同時采用AOP編程模型，取代了傳統的面向對象設計（OOSD）中，組件的直接組合和繼承耦合，有效地消除了服務和倉儲組件對領域模型的結構污染。Takia采用標準的生產者?消費者（Producer?Consumer）設計模式構架領域消息模型，并針對虛擬機內部機制進行有效的優化，除了支持普通的JDK一對一同步/異步消息以外，還提供了高并發環境下的基于Disruptor框架的一對多異步消息支持，有效地解決了傳統JavaEE分層構架的高并發環境下系統吞吐量迅速衰減的問題。下面依次對JDK和Disruptor兩種消息模型結構進行分析。

2.1 JDK?Future消息模型設計

Future消息模型基于JDK的Concurrent包實現，核心組件是ChannelExecutor。該組件由一個線程池（ThreadPool）和一個同步組件組成，用于運行消息監聽器（MessageListener）。當使用異步模式時，由ThreadPool來運行MessageListener；使用同步模式時，由同步組件將MessageListener放入當前線程中執行。Future消息模型的詳細結構和處理過程如圖2所示。

由圖2可以看出，DomainMessage作為消息生產者DomainObject和消息消費者MessageListener之間的橋梁用以傳遞信息，由事件源（EventSource）和Future結果事件（FutureResultEvent）組成，結果事件中包含了結果對象，事件元數據配置和一個FutureTask對象，FutureTask作為簡單的內存障（MemoryBarrier），與ChannelExecutor配合使用用以保證消息的一致性。由于受到Future機制的限制，在Future模式下只支持1∶1的生產者和消費者通信模式。

圖2 Future消息模型的詳細結構和處理過程

消息過程由DomainObject發起，通過調用DomainEvents（消息總線）創建一個DomainMessage對象后，DomainObject將事件源（EventSource）傳遞給DomainMessage（事件源即DomainObject傳遞給MessageListener的信息）；接著DomainEvents會通知消息攔截器（MessageInterceptor）對DomainMessage的ResultEvent進行初始化，完成消息創建過程；然后MessageInterceptor調用EventMessageFirer發送消息，EventMessageFirer將Future消息的發送委托給FutureFirer，其根據消息配置從IoC容器中獲取MessageListener組件后和DomainMessage一起放入ChannelExecutor執行。

對于同步消息，ChannelExecutor使用同步組件在當前線程中運行MessageListener，對于異步消息，ChannelExecutor會將MessageListener放入ThreadPool中執行。MessageListener可以在業務完成以后對DomainMessage設置結果對象（EventResult），最后作為消息生產者的DomainObject可以通過DomainMessage的getEventResult方法獲取MessageListener處理結果，該方法可以被多次調用，并返回同一結果。在該模式下，DomainMessage的FutureTask會保證結果的可用性和一致性。

2.2 Disruptor消息模型設計

Disruptor消息模型基于并發編程框架Disruptor實現[5?6，8]，采用全異步模式實現，核心結構由一個輸入區域（Input Disruptor）和一個輸出集合（Output Disruptors）組成。Disruptor模式支持1∶N消息模式。Input Disruptor的環形緩沖區（RingBuffr）可以同時運行多個消息處理器（MessageListener），同時每一個DomainMessage都擁有自己的Output Disruptor，可以獨立的設置處理結果，互不干擾，Disruptor消息模型的詳細結構和處理過程如圖3所示。圖3在Disruptor模式下DomainMessage由事件源（EventSource）和Disruptor結果事件（DisruptorResultEvent）組成，結果事件中包含事件元數據配置和一個事件處理器（ValueEventProcessor）對象，事件處理器用于讀/寫結果輸出區域的RingBuffer。Disruptor模式下支持1∶N的生產者和消費者主體訂閱模式（Topic Subscription）。與Future模式的流程類似。

圖3 Disruptor消息模型的詳細結構和處理過程

Takia管理RingBuffer的策略是為每一個Topic創建一個Input Disruptor實例，而為每一個DomainMessage對象創建一個獨立的Output Disruptor實例，所以一個Input Disruptor會對應多個Output Disruptors，他們之間完全獨立互不影響。為了在性能和資源占用上取得平衡，Takia默認使用Disruptor的Blocking等待策略。

3 基于消息的領域模型實現

與傳統的分層式構架體系不同，Takia采用以領域為核心的輻射型結構。客戶端的請求到達服務器以后，MVC控制器作為DDD的Facade使用，用于從緩存中獲取領域實體對象或者構建新的領域對象等；業務邏輯不再通過直接的服務調用，而是通過領域對象之間以消息的方式相互作用來完成。一個領域通過領域服務對象來組織整體業務，領域也有能力實現自身的領域服務，這些交互均通過領域事件來觸發，信息通過領域消息來傳遞。Takia對領域緩存和領域消息均采用Spring AOP和Auto?Proxy的透明機制實現，對業務組件零入侵，基本對現有開發方式不造成影響。Takia DDD的編程模型設計[5]如圖4所示。

圖4 Takia DDD的編程模型設計

由圖4可知，Takia DDD替換了Spring原有的業務層和持久層，采用以領域容器為核心的輻射結構。在該模型中，SpringUI和MVC組件充當Facade使用，當截獲用戶請求以后，會對請求進行解析和封裝，形成DDD的語義形式[7]，傳遞給Takia DDD。Takia首先從領域模型容器（ModelContainer）中提取該請求所對應聚合根（Aggregation Root）對象，通過對象圖遍歷（Object Graph Iteration）找到請求所需業務實體（Entity）對象，模型容器中的實體對象均為富對象模型（RichModel）。在業務處理過程中，實體可直接調用自己的相關方法完成業務處理，將結果返回表現層組件，然后返回給客戶端，整個處理過程結束。該過程存在的問題與解決方案：

（1） 領域對象與ORM對象的生命周期（LifeCycle?LC）不匹配問題。在ORM框架體系下，對象的生命周期與會話同步，一個會話只會在一次請求的過程中提供服務。會話關閉后，ORM對象將會被終結，隨著事務提交，將對象數據從內存更新到數據庫，這種模型也是造成系統對數據庫產生依賴的主要原因；與此相反，DDD的對象模型是內存駐留（In Memory）模型，理論上只要該領域沒有被銷毀，都應該在內存中存在。當然在實際項目開發過程中，由于內存始終是有限的，所以在實際項目開發過程中一般采用內存領域緩存配合模型加載器（ModelLoader）或者AOP緩存攔截器（CacheInterceptor）的方式來實現面向內存的領域體系。

（2） 領域實體對象與服務，倉儲等組件的交互問題。在JavaEE的框架體系中，基本采用直接耦合方式，即直接通過IoC容器配合Interceptor實現對領域對象的依賴組件進行注入，讓領域支持業務功能。該方式比較直觀，理解也比較容易，但是缺點是會對領域模型造成污染。隨著業務增大，使得領域對象變得的臃腫、領域維護難度迅速增加；在目前的一些基于動態語言（Ror，Grails）的構架中，通過語言的動態特性讓領域對象動態地支持業務功能，甚至Java現在也有框架利用Aspectj實現了類似的效果（如Spring Roo）。

該方法雖然降低了領域對象的污染程度，但是其編程模型與直接組件注入完全相同，沒有從本質上改變業務的處理方式，對業務系統的性能提升沒有任何作用。而本文采用的是事件驅動的思想來構建Takia，組件之間的信息傳遞通過消息總線來完成。其中同步消息跟目前的編程模型一致，而異步消息通過多線程和并發隊列框架，消除了請求處理的阻塞，請求和處理分別在不同的模塊中進行處理，只有在必要的時候進行同步，大大提高了業務系統的處理性能。從圖4可以看出，在Takia中領域組件和業務組件之間通過本地DomainMessage消息傳遞信息，沒有任何其他耦合關系；同時Takia通過消息翻譯器（MessageTranslator）支持本地消息同分布式JMS消息系統的無縫切換。

4 結 語

針對目前JavaEE的分層構架出現的領域失配、性能低下和DDD理論與實踐之間的不兼容等問題，本文在Evans DDD理論和Spring框架的基礎上，實現了一個基于領域消息驅動和內存建模的DDD插件Takia。在不影響目前系統架構的基礎上，使項目實施完全兼容DDD設計，同時基于消息的通信機制也能更有效地解耦系統模塊，并大大提高了系統并發性能，為JavaEE的企業信息系統建模提供了一種全新的思維方式。在項目實踐中證明，Takia比傳統的分層模型更加合理高效。

參考文獻

[1] 杜佳.對象/關系映射技術在信息系統開發中的應用研究[D].西安：西安電子科技大學，2011.

[2] Eric Evans.領域驅動設計[M].北京：清華大學出版社，2006.

[3] 秦秀磊，張文博，魏峻，等.云計算環境下分布式緩存技術的現狀與挑戰[J].軟件學報，2013（1）：50?66.

[4] 陳濤，黃強，倪少權.鐵水聯運信息整合的框架研究方案[M].北京：鐵道部，2011.

[5] 黃強，錢文輝.Takia?DDD構架及詳細設計說明書[M].上海：上海瑞瀚科技有限公司，2012.

[6] 黃強，王薇，倪少權.基于SOA和DDD的鐵水聯運信息平臺構架設計[J].計算機應用與軟件，2013（6）：124?126.

[7] Bluishglc.領域驅動設計（Domain Driven Design）參考架構詳解[EB/OL].[2011?08?12].http：//blog.csdn.net/bluishglc/article/de

tails/6681253.

[8] 丁濤.基于領域驅動設計的物流平臺系統實現[D].成都：電子科技大學，2010.