企業應用架構模式中的層次模型簡介

企業對外提供服務，一般藉助於軟件應用。好比交易零售系統，用來提供購買商品的服務，這裏就涉及到交易數據，這些數據會被用戶「反覆」的產生、查看，並且隨着服務時間增加，應用自己也會面臨困難

• 業務邏輯。業務自己是有必定的邏輯性的，但會常常出現特殊的業務場景，致使出現"無邏輯"的複雜業務
• 數據增加。應用自己會產生大量的數據，他們天天會被大量的用戶同時操做、同時訪問，須要確保最終數據的表現是符合預期的
• 三方依賴。企業應用自己會與其它企業應用集成，與不一樣的企業應用集成面臨不一樣的風格
• 開發效率。一方面必須快速的開發出來，一方面又要考慮後續發展的可能性，若是不作後續發展的考慮，靈活性不夠，會帶來額外的複雜性，影響系統發展，但這額外的考慮又會可能「挑戰」開發進度，影響效率
• 應用性能。響應時間、吞吐率、負載、容量、可伸縮性

架構模式基本概念

架構

架構是一種主觀上的東西，是對系統設計的一些可共享的「主觀理解」，可共享性表如今系統中主要的組成部分以及他們之間的交互關係。對架構的定義可以統一的內容有兩點:

1. 最高層次的系統分解
2. 系統中不易更改的決定

模式

模式描述了一個在咱們周圍不斷重複發生的問題以及該問題解決方案的核心，這樣可以一次又一次的使用該方案而不用作重複的勞動

使用分層分解複雜軟件系統的優劣

層次模型致力於將企業應用組織成不一樣的層次，並協調各層次之間的關係

• 優點：一層能夠做爲一個有機總體，無需理解其它層次；一層是能夠替換的，只要保證層次的服務同樣；只要構建好了一層就可以爲不少上層同時提供服務；分層以後有利於標準化；層次之間的依賴性下降
• 劣勢：層次不能封裝全部的東西，好比數據庫加了一個字段，會形成級聯修改；過多的層次會影響性能

三層架構的系統

• 表現層：處理用戶與軟件的交互，好比HTML界面
• 領域層：處理業務邏輯，根據表現層獲得的數據，進行驗證、計算以及肯定使用哪一個數據源進行存儲
• 數據源層：與數據庫、消息系統、事務管理器等交互，大多數就是持久化數據

這裏的層次是邏輯上的，不必定是物理上的隔離，全部層能夠在1個服務器上，也能夠是多個物理機

組織領域邏輯的方式

有三種組織形式 事務腳本、領域模型、表模塊。

他們之間並不互相排斥，能夠在事務腳本中處理部分領域邏輯，同時使用表模塊或者領域模型來處理剩下的部分

事務腳本

使用過程來組織業務邏輯，每一個過程處理來自表現層的單個請求。簡單的來講就是從表示層得到輸入、進行校驗和計算處理、將數據存儲到數據庫中以及調用其它系統的操做等等

• 優勢：使用過程模型簡單易懂；可以與簡單數據源層很好的協做；事務邊界清晰
• 缺點：多個事務要作相同的事情或者相似的動做時，拆分提取公共的子例程棘手，容易致使程序結構雜亂無章

領域模型

合併了行爲和數據的領域的對象模型（每一個類都有行爲和數據，類之間交互來完成任務）。簡單來講就是每一個對象都承擔一部分相關邏輯

• 優勢：可以利用現成的技術來組織日趨複雜的領域邏輯（前期準備好了，後期好使用）
• 缺點：使用複雜、數據源層複雜

表模塊

處理某一數據庫表或視圖中全部行的業務邏輯的實例，它處於領域模型和事務腳本的中間地帶

• 優勢：可以與已有部分更好的銜接，在過程的基礎上增長了更多的結構，更容易移除冗餘邏輯
• 缺點：沒法組織與領域模型同樣的細粒度邏輯結構技術

不一樣領域組織方式區別示例

案例：對於一個給定的合同，不一樣的產品種類有不一樣的收入確認算法，須要計算給定合同的收入

事務腳本與領域模型的區別：

• 事務模型會有一個收入服務，它的計算收入方法會包含全部的業務邏輯，內部調用的全部下層方法僅僅負責把數據值返回給事務腳本任務
• 領域模型會有多個對象，每一個對象都會向前傳遞一部分行爲給另外一個對象，直至最終建立告終果

表模塊與領域模型的區別：

• 領域模型對每個合同都有一個相應的合同類的實例
• 表模塊是隻有一個公共的合同類實例

領域模型與表模塊的細分

獨立出一個服務層放在領域模型與表模型之上，服務層自己有3種形式

1. 僅傳遞上層到下層，全部的實際行爲都在下層。此時它用於提供更易於使用的API，也能夠做爲切入點增長事務封裝和安全檢查
2. 在服務層使用事務腳本的形式組織全部的業務邏輯，使得下層的領域對象變簡單
3. 控制器-實體 形式。它折中於1和2，將單個事務或用例所特有的邏輯置於事務腳本之中

能夠在有要的時候才加服務層，若是加了也要最小化

從架構模式看領域邏輯訪問數據庫的方式

以數據庫的表結構爲基礎，每張表對應一個類，這種類爲數據庫訪問提供了’入口‘。

應用程序其它部分就不須要關心SQL

入口使用方法有兩種

1. 行數據入口，爲查詢語句的每一行產生一個它的實例(簡單來講查詢的列不一樣，返回的VO不一樣)
2. 表數據入口，數據庫中的每一個表僅用一個對象來管理(簡單來講不一樣的查詢，返回同一種結構的記錄集)

數據映射器

在簡單的領域模型中，模型自己和表至關一致，這時可讓領域對象自己去負責數據庫的存儲過程（也稱做活動記錄）,它實際就是以行數據入口開始，把領域邏輯加入到類中，可是當領域模型複雜時，入口能夠解決一些問題，可是這實際上是讓數據庫方案和領域方案冗餘在一塊兒，致使部分入口域和領域對象域的轉換，使得領域對象變得複雜，這時可使用數據映射器，它來處理數據庫和領域模型之間的全部存取操做，而且容許兩者獨立變化，使兩者徹底獨立

工做單元

使用活動記錄可以解決簡單的讀取和存儲操做，可是涉及到讀取同時修改再存儲等複雜操做，必須保證數據庫的一致性，這種狀況就能夠工做單元解決。
工做單元用來充當數據庫映射的控制器，它會跟蹤全部從數據庫讀取對象以及任何形式修改對象，同時也負責從新提價到數據庫。

簡單的狀況是由領域本身來完成，複雜狀況則是交給了工做單元來作

結構映射模式

處理關係映射

表結構以前通常存在着 一對多，多對多這種結構，對象也須要處理好這種映射關係，方法則是在對象中使用一個標識域來保持對象之間的關係特性，並經過查找這些值來保持對象引用與關係鍵之間的映射。

並非全部的關係都須要外鍵與關係域這種映射，若是值對象很小，可使用序列化的方式直接存儲到關聯對象的一列中

對象的繼承關係在表結構中的映射

對象自己存在繼承關係，這個時候將這種結構映射到表中一般有如下三種方式：

1. 單表繼承，爲一個層次中的全部類創建一張表
2. 具體表繼承，爲每一個具體的類建一個表（每張表包含類的全部字段）
3. 類表繼承，爲這個層次中的每個類建一張表（每張表不包含父類的字段）

類表繼承一般須要多個鏈接，損失了性能；具體表該表很麻煩，一旦父類變動，全部的表都得改動；單表存在着空間浪費，單表過大也影響性能，可是修改容易並且不用鏈接

根據應用場景選擇具體方式

表現層的視圖模式

模板視圖：在網頁結構中編寫表現層，並容許在網頁中嵌入標籤，用以指明網頁中的動態內容須要導向哪裏，好比JSP 轉換視圖：將領域層返回的數據轉換到表現成對應的結構位置上，好比根據後端的json數據反映到對應的樣式表單

單階視圖與兩階視圖

單階視圖：爲每一個屏幕準備一個視圖組件，視圖提取領域數據並把它返回到HTML網頁中 兩階視圖：首先根據領域數據產生一個邏輯屏幕，而後發往HTML網頁。每一個屏幕自己都已經有了一個第一階段的視圖，而程序中只有一個第二階段的視圖

兩階視圖能夠決定把什麼樣的HTML網頁用在什麼地方,另外多端（PC/PAD/手機）經過不一樣的邏輯屏幕可以展現不一樣的外觀視圖

附錄

<企業應用架構模式> 1-4 章