一種領域驅動開發插件系統的制作方法
【技術領域】
[0001]本發明屬于網絡通信領域，尤其涉及一種領域驅動開發插件系統。
【背景技術】
[0002]作為系統數據存儲和分析的核心，數據庫在信息系統中起著重要作用，目前的企業級應用平臺開發和設計必須依賴于關系數據庫，數據庫在發揮巨大作用的同時，其模式結構也與主流的面向對象系統分析理論產生了較大的縫隙，隨著系統規模不斷增大，基于過程和事務腳本的系統分析方法已經不能滿足業務需求。
[0003]基于00技術構建的領域建模理論，為大規模業務系統分析提供了有力的理論指導，隨著這方面理論不斷地成熟，已經逐漸應用到各個領域的系統分析和構架中。領域建模(Domain Modeling-DM)的初期是基于對象關系映射的ORM (Object Relat1nshipMapping)技術，ORM通過數據庫與對象的數據映射，解決了關系與對象的不匹配問題，讓系統設計分析人員能夠用純粹的對象技術來解決領域問題。但是隨著業務分析的深入，ORM產生的貧血對象模型由于行為能力的缺失，讓系統又從對象模型退化為事務處理過程，與DM理論逐漸背離。隨后為了避免貧血模型的弊端而出現的充血模型，將業務與數據全部合并到領域模型中，有很多框架都是在充血模型的理論基礎上進行了大量實踐(如ROR, Grails, Spring Roo等)，這些快速開發框架在小型項目上應用非常成功，因為其模板式的開發方式，強大的動態方法生成，以及快速腳手架(Scaffolding)等特性，讓充血領域模型有了強大的功能。但是隨著業務增長，領域對象急速膨脹，維護難度也在增加，使系統處于一個不可控的狀態，并且業務和數據的領域整合使系統的結構變得模糊不清，所以這類框架始終沒有成功的應用到大型項目開發中。
[0004]一種基于四色原型的領域開發模型Evans DDD，強調領域設計必須以業務為指導，Evans DDD不但彌補了 ORM的對象行為缺失和生命周期問題，也通過領域聚合和分解有效地解決了充血模型隨著領域的擴大而臃腫的缺陷，為大型系統設計和開發提供了一個合理的解決途徑。由于Evans DDD的設計理念比較靈活，系統開發和設計人員對該理論進行了很多的實踐并取得了較多成果，但是始終沒有一個統一的底層技術構架來支持該模型。這不但給該理論的推廣造成了極大的障礙，沒有統一的構架支持，系統開發人員也很難將系統分析轉換為編碼，大大降低了系統的實施效率。同時現有的框架體系基本是以數據庫為核心的分層結構，也為DDD的實踐造成了很大的障礙，一些全新的框架由于不能很好的兼容以前的遺留系統，也很難得到推廣。
[0005]DDD是完全基于內存的業務對象建模(In-Memory)方法,但是在項目實施過程中，目前的開發框架均依賴于關系數據庫系統，ORM雖然在數據庫與業務系統之間進行了橋接，但只支持貧血模型且對象生命周期無法DDD匹配，造成系統實施過程與設計不相符；現有的DDD框架不能完全覆蓋系統業務，也不成熟穩定，無法應用于實際項目的開發。
【發明內容】
[0006]本發明實施例提供一種領域驅動開發插件系統，旨在解決現有技術中JavaEE的分層構架出現領域失配、性能低下及DDD理論與實踐不兼容的問題。
[0007]本發明實施例是這樣實現的，一種領域驅動開發插件系統，所述系統包括:
[0008]命令查詢分離體系設計單元，用于分離領域模型中的業務過程與數據查詢；
[0009]消息代理單元，用于使領域與外界通信，并支持本地消息，以及分布式消息；以及
[0010]消息模型設計單元，用于通過領域消息實現領域組件的信息交互，采用并發的事件驅動模式及AOP編程模型。
[0011]本發明實施例根據DDD理論及Spring框架，實現了一個基于領域消息驅動和內存建模的DDD插件Takia，使項目實施完全兼容DDD設計，同時基于消息的通信機制能有效的解耦系統模塊，提高系統并發性能，在項目實施中更加合理高效。
【附圖說明】
[0012]圖1是本發明實施例提供的領域驅動開發插件系統的結構圖；
【具體實施方式】
[0013]為了使本發明的目的、技術方案及優點更加清楚明白，以下結合附圖及實施例，對本發明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發明，并不用于限定本發明。
[0014]本發明實施例基于Spring框架，實現了一種基于領域消息驅動及內存建模的DDD插件Takia，使項目實施完全兼容DDD設計，同時基于消息的通信機制能有效解耦系統模塊。
[0015]圖1示出了本發明實施例提供的領域驅動開發插件系統的結構，詳述如下:
[0016]命令查詢分離體系設計單元12分離領域模型中的業務過程與數據查詢。
[0017]在本發明的實施例中，基于Takia的業務過程由命令總線和查詢總線構成，該查詢分為模型查詢及組合查詢，均支持分頁查詢。
[0018]在本發明的實施例中，命令查詢分離體系設計單元12包括:模型創建流程設計模塊121，模型更新流程設計模塊122，模型刪除流程設計模塊123以及模型查詢流程設計模塊 124。
[0019]模型創建流程設計模塊121根據用戶數據創建模型對象和相關值對象。
[0020]模型更新流程設計模塊122根據用戶數據修改已經存在的模型對象和相關值對象。
[0021]模型刪除流程設計模塊123根據用戶數據刪除已經存在的模型對象和相關值對象。
[0022]模型查詢流程設計模塊124根據查詢條件查詢模型數據列表。
[0023]消息代理單元13使領域與外界通信，并支持本地消息，以及分布式消息。
[0024]消息模型設計單元14通過領域消息實現領域組件的信息交互，采用并發的事件驅動模式及AOP編程模型。
[0025]在本發明的實施例中，領域消息模型根據標準的生產者一消費者設計模式構架。
[0026]在本發明的實施例中，消息模型設計單元14包括JDK-Future消息模型設計模塊141以及Disruptor消息模型設計模塊142。
[0027]JDK-Future消息模型設計模塊141根據Future消息模型運行消息監聽器。
[0028]在本發明的實施例中,Future消息模型基于JDK的Concurrent包實現,核心組件為ChannelExecutor,由線程池和同步組件組成,若使用異步模式，則線程池運行消息監聽器，若使用同步模式，則同步組件將消息監聽器放入當前線程中執行。
[0029]Disruptor消息模型設計模塊142根據Disruptor消息模型同時運行多個消息處理器，獨立設置處理結果。
[0030]在本發明的實施例中,Disruptor消息模型基于并發編程框架Disruptor實現,采用全異步模式且支持1:N消息模式，核心結構由輸入區域和輸出集合組成。
[0031]作為本發明的一個優選實施例，該領域驅動開發插件系統還包括衛星結構模型設計單元11。
[0032]衛星結構模型設計單元11通過與核心領域的消息交換實現業務邏輯，且以實體領域為核心。
[0033]在本發明的實施例中，領域驅動開發插件系統以實體對象、值對象、聚集以及領域事件為基礎，采用分布式緩存實現領域的In-Memory模型。
[0034]在本發明的實施例中，該系統采用以領域容器為核心的輻射結構，對領域緩存及領域消息均采用SpringAOP及Auto-Proxy的透明機制實現。
[0035]本發明實施例根據DDD理論及Spring框架，實現了一個基于領域消息驅動和內存建模的DDD插件Takia，使項目實施完全兼容DDD設計，同時基于消息的通信機制能有效的解耦系統模塊，提高系統并發性能，在項目實施中更加合理高效。
[0036]以上所述僅是本發明的優選實施方式，應當指出，對于本技術領域的普通技術人員來說，在不脫離本發明原理的前提下，還可以作出若干改進和潤飾，這些改進和潤飾也應視為本發明的保護范圍。
【主權項】
1.一種領域驅動開發插件系統，其特征在于，所述系統包括: 命令查詢分離體系設計單元，用于分離領域模型中的業務過程與數據查詢； 消息代理單元，用于使領域與外界通信，并支持本地消息，以及分布式消息； 消息模型設計單元，用于通過領域消息實現領域組件的信息交互，采用并發的事件驅動模式及AOP編程模型。
2.如權利要求1所述的系統，其特征在于，所述分離領域模型中的業務過程由命令總線和查詢總線構成，所述分離領域模型中的數據查詢分為模型查詢及組合查詢，均支持分頁查詢。
3.如權利要求1所述的系統，其特征在于，所述命令查詢分離體系設計單元具體包括: 模型創建流程設計模塊，用于根據用戶數據創建模型對象和相關值對象； 模型更新流程設計模塊，用于根據用戶數據修改已經存在的模型對象和相關值對象； 模型刪除流程設計模塊，用于根據用戶數據刪除已經存在的模型對象和相關值對象； 模型查詢流程設計模塊，用于根據查詢條件查詢模型數據列表。
4.如權利要求1所述的系統，其特征在于，所述領域消息模型根據標準的生產者一消費者設計模式構架。
5.如權利要求1所述的系統，其特征在于，所述消息模型設計單元具體包括: JDK-Future消息模型設計模塊，用于根據Future消息模型運行消息監聽器；以及 Disruptor消息模型設計模塊,用于根據Disruptor消息模型同時運行多個消息處理器，獨立設置處理結果。
【專利摘要】本發明適用于網絡通信領域，提供了一種領域驅動開發插件系統，所述系統包括：命令查詢分離體系設計單元，用于分離領域模型中的業務過程與數據查詢；消息代理單元，用于使領域與外界通信，并支持本地消息，以及分布式消息；消息模型設計單元，用于通過領域消息實現領域組件的信息交互，采用并發的事件驅動模式及AOP編程模型。本發明根據DDD理論及Spring框架，實現了一種基于領域消息驅動和內存建模的DDD插件Takia，使項目實施完全兼容DDD設計，同時基于消息的通信機制能有效的解耦系統模塊，提高系統并發性能，在項目實施中更加合理高效。
【IPC分類】G06F17-30, G06F17-40, G06F9-44
【公開號】CN104636333
【申請號】CN201310544634
【發明人】張飛
【申請人】寧夏新航信息科技有限公司
【公開日】2015年5月20日
【申請日】2013年11月6日