[發明專利]一種基于DDD充血模型及CQRS的代碼架構優化系統

在審

• 申請號: 202011037796.X
• 申請日: 2020-09-28
• 公開（公告）號: CN112181375A
• 公開（公告）日: 2021-01-05
• 發明（設計）人: 李燦
• 申請（專利權）人: 浪潮云信息技術股份公司
• 主分類號: G06F8/20
• 分類號: G06F8/20;G06F8/30;G06F8/75
• 代理公司: 濟南信達專利事務所有限公司 37100
• 代理人: 闞恭勇

本發明提供一種基于DDD充血模型及CQRS的代碼架構優化系統，屬于軟件/數據處理技術領域，本發明包括架構分層、領域實體和查詢模型；在主流三層架構背景下，通過架構分層的劃分、領域實體的優化、查詢模型的拆分，實現業務邏輯不依于實現細節等諸多特性。

技術領域

本發明涉及軟件/數據處理技術，尤其涉及一種基于DDD充血模型及CQRS的代碼架構優化系統。

背景技術

在軟件架構中，三層架構已經成為主流。三層架構是將整個業務應用劃分為：界面層(表示層、表現層)、業務邏輯層、數據訪問層。界面層顯示數據和接收用戶傳輸的數據，為軟件提供交互式操作界面。業務邏輯層對具體問題進行業務邏輯判斷與處理，實現三層之間的數據連接和指令傳達。數據訪問層提供了對數據庫中數據的增加、刪除、修改、查詢等操作。三層中的數據傳遞通常由業務實體(entity)或數據傳輸對象(data transferobject)承擔。

三層架構本質上是一種面向過程的編程思想，其特點如下：

1.業務實體類中只有屬性沒有方法。

2.業務邏輯層的類中只有方法沒有屬性。

3.通常將數據表結構映射為業務實體類。

三層架構的根本問題在于：內存模型通常與數據庫模型保持一致。如果數據庫模型粒度很小，大量的表連接導致難以開發、維護以及性能問題。如果數據庫模型粒度很大，代碼的質量(重用性、穩定性、擴展性)就會很差。由于沒有從業務的角度去仔細定義每一個類，會導致隨著業務的發展相關類持續增長且難以維護。更有甚者，將業務邏輯也寫進SQL或JS語句里。

發明內容

為了解決以上技術問題，本發明提供了一種基于DDD充血模型及CQRS的代碼架構優化方法。

本發明的技術方案是：

一種基于DDD充血模型及CQRS的代碼架構優化系統，

包括架構分層、領域實體和查詢模型；

所述架構分層包括領域層、用例層、適配層和框架層，其依賴關系為由外向內的；

所述領域實體采用包含屬性和行為的實體對象設計；

所述查詢模型分離了客戶端的查詢操作。

進一步的，

領域層封裝了核心業務規則，一個領域實體既包含屬性和行為，能以業務實體為核心靈活擴展；

用例層包含應用業務規則，整合并且實現了系統中需要的所有用例，這些用例協調著來往于實體之間的數據流；

適配層包含各種適配器，負責把從領域層和用例層流出來的數據轉換成為更外面一層需要的數據格式；

框架層是最外面的一層，是很多工具或庫的具體實現細節所在。

領域實體應該遵循面向對象設計，領域模型具備自己的屬性行為狀態，并與現實世界的業務對象相映射。

領域實體具備明確的職責劃分，領域對象元素之間通過聚合和引用關系配合解決實際業務應用和規則。

進一步的，

采用獨立的查詢模型

將客戶端請求分為命令和查詢，命令通過領域對象進行增加、修改、刪除業務邏輯操作，查詢通過查詢模型將數據庫中的數據轉換成需要的形式予以返回。

查詢模型根據UI的需求變化而變化，同時隔離領域對象不受此變化的影響。

進一步的，