第九天-《企業應用架構模式》-領域邏輯模式

pinecone 發布于2019-07-01 11:18 / 2758人閱讀

摘要：領域模型應當使用細粒度的對象，這些對象應有細粒度的接口。它封裝了應用的業務邏輯事務控制及其操作實現中的響應協調。

1. 事務腳本 1）調用數據庫：

事務腳本將所有邏輯組成單個過程，在過程中直接調用數據庫，或者只通過一個簡單的數據庫封存器。

2）腳本處理：

每個事務都有自己的事務腳本，盡管事務間的公共子任務可以被分解成多個子程序。

3）運行機制：

a.事務腳本應該置于與其他處理表現層和數據源層的類相獨立的類中，把事務腳本組織成類的兩種方法：

a. 將數個事務腳本放在一個類中，每個類圍繞一個主題將相關的事務腳本組織在一起；

b. 使用Command模式，每一個事務腳本對應一個類 (command)

4）使用時機:

業務邏輯簡單場景（同時注意謹慎提取公共子程序以減少代碼冗余），當業務復雜時則需要建立領域模型

5）優點：

當問題本身是簡單的時，使用事務腳本可以加快開發速度，而且運行更快

6）示例：

假如有如下需求：

數據庫設計為：

其中，RevenueRecognition表引用Contract表的Id作為外鍵。根據需求和數據庫設計，事務腳本類圖設計為：

這里，Gateway為數據庫訪問封存器，RecognitionServices為事務腳本類。CalculateRevenueRecognitions方法用于計算并保存需入賬信息（合同編號、時間、收費金額），RecognizedRevenue用于按照合同編號、指定日期查詢已收費用。應用程序只需要分別單個調取這2個方法即可。

2. 領域模型 1）運行機制

領域模型與數據庫模型的區別：領域模型混合數據和處理過程，擁有多值屬性和復雜的關聯網，并且使用繼承、策略、設計模式，是一張由互聯的細粒度對象組成的復雜網絡；

使用領域邏輯的一個常見問題: 領域對象過于臃腫，可能會產生冗余代碼

數據庫映射：簡單領域模型可以使用活動記錄，而復雜領域模型需要使用數據映射器。

領域模型應當使用細粒度的對象，這些對象應有細粒度的接口。

2）使用時機

當業務規則復雜多變，涉及到校驗、計算、衍生時。

數據庫交互方式：首選數據映射器

3）示例：

對于上文中需求，設計類圖如下：
　　　　

可以看到，這里收費方式使用了策略模式。

3. 表模塊

表模塊以一個類對應數據庫中的一個表來組織領域邏輯，而且使用單一的類實例來包含將對數據進行的各種操作程序。

表模塊與領域邏輯的區別：如果有多個訂單，領域模型對每個訂單都有一個對象，而表模塊則只用一個對象來處理所有訂單（表模塊沒有標識符來標出它所代表的實體對象）。

1）運行機制

長處：允許你將數據與行為封裝在一起，同時有可以充分利用關系數據庫的優點

2）使用時機

當使用記錄集存取表數據時使用（表模塊很大程度上依賴于以表方式組織的數據）
　　

3）示例：

設計類圖如下：
　　
　　　　

4. 服務層

服務層定義了應用的邊界和從接口客戶層角度所能看到的可用操作集。它封裝了應用的業務邏輯、事務控制及其操作實現中的響應協調。
　　

1）運行機制

業務邏輯分類：領域邏輯、應用邏輯

兩種基本的實現方法：

領域外觀方法：

服務層以領域模型之上的瘦外觀集合方式實現（負責實現外觀的類不包含任何業務邏輯，所有業務邏輯均由領域模型實現）

操作腳本方法：

服務層由一組相對復雜的類組成，這些類直接實現應用邏輯，但將領域邏輯委托給封裝好的領域對象類

服務層接口時粗粒度的，必要時候可以遠程調用（在服務層之上增加遠程外觀或者直接讓服務層實現遠程接口）
　　

2）使用時機 服務層優點：

它定義了一個公共的應用操作集合，這個集合可被各種客戶使用，而且服務層在每個操作中都會協調應用的響應。

當業務邏輯有多種客戶，或者用例響應中的多個事務性資源，則需要服務層

云服務器 GPU云服務器架構模式軟件架構模式大數據架構模式數據庫架構模式

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/30075.html

第十天-《企業應用架構模式》-數據源架構模式

摘要：運行機制表數據入口包含了用于訪問單個表或試圖的所有，如選擇插入更新刪除等。其他代碼調用它的方法來實現所有與數據庫的交互。示例如下圖分別是普通情況下充分利用特征下的表數據入口實現行數據入口充當數據源中單條記錄入口的對象，每行一個實例。 1. 表數據入口　　充當數據庫表訪問入口的對象，一個實例處理表中所有的行。 1）運行機制：　　　　表數據入口包含了用于訪問單個表或試圖的所有SQL，如...

Drummor 2019-07-01 11:18 評論0 收藏0
第二天-《企業應用架構模式》-組織領域邏輯

摘要：模型抉擇領域邏輯復雜度抉擇領域邏輯復雜度較低時，選擇事物腳本如果開發環境擁有大量基于記錄集的工具和，可以選擇表模塊開發小組經驗豐富時，選擇領域模型種模式并不互相排斥，可以同時使用服務層服務層是從領域層分離出來的，用于置于底層的領域模型或表模 1. 模型抉擇： 1）領域邏輯復雜度：　　showImg(https://segmentfault.com/img/remote/1460000...

wwolf 2019-07-01 11:15 評論0 收藏0
第三天-《企業應用架構模式》-映射到關系數據庫

摘要：如果數據非常類似，可把數據從內存方案中轉化到邏輯數據存儲方案，映射從邏輯數據存儲方案到實際物理存儲方案第二部包含區別使用元數據元數據映射基于把映射濃縮到元數據文件的方法。元數據文件詳細描述數據庫中列如何映射到對象的域。關系數據庫之所以取得成功，最重要的原因之一就是SQL的存在，它是數據庫通信標準語言。 1. 架構模式：驅動領域邏輯訪問數據的方式： SQL語句嵌入在程序設計語言中； ...

chenatu 2019-07-01 11:15 評論0 收藏0
企業應用架構模式-30天閱讀計劃

摘要：企業應用在某些方面要比電信軟件簡單得多多線程問題沒有那么困難，無需關注硬件設備與軟件的集成。但是，在某些方面，企業應用又比電信軟件復雜得多企業應用一般都涉及到大量復雜數據，而且必須處理很多不合邏輯的業務規則。構建計算機系統并非易事。隨著系統復雜性的增大，構建相應軟件的難度將呈指數增大。同其他行業一樣，我們只有在不斷的學習中進步，從成功經驗中學習，從失敗教訓中學習，才有望克服這些困難...

null1145 2019-07-01 11:15 評論0 收藏0
一文讀懂微服務架構的重構策略

摘要：相反，它由單體中的適配器和使用一個或多個進程間通信機制的服務組成。因為微服務架構的本質是一組圍繞業務功能組織的松耦合服務。如果你嘗試將此類功能實現為服務，則通常會發現，由于過多的進程間通信而導致性能下降。這是快速展示微服務架構價值的好方法。你很有可能正在處理大型復雜的單體應用程序，每天開發和部署應用程序的經歷都很緩慢而且很痛苦。微服務看起來非常適合你的應用程序，但它也更像是一項遙不可及的必殺...

jaysun 2019-05-22 19:25 評論0 收藏0