企業對外提供服務，通常藉助於軟體應用。比如交易零售系統，用來提供購買商品的服務，這裡就涉及到交易資料，這些資料會被使用者“反覆”的產生、檢視，而且隨著服務時間增長，應用本身也會面臨困難

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

架構模式基本概念

架構

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

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 章