Author: Anders小明
為何要Domain Model
傳統的開發方式：基于數據庫的設計開發。數據庫提供的設計模型是表和字段兩種粒度，這兩種粒度有時并不合適于系統設計：
1. 模型的結構化能力
1.1. 同一模塊組件下的設計優勢；一個model可以來自多張表的數據聚合而成，一張表可以聚合多個Model；一個邏輯是由幾個固定字段或者非固定字段聚合；Model間的關聯關系也是使用表無法展示的（外鍵的約束對于系統開發來說實在太有限了）。而這些不論表還是字段粒度都無法支持的！
1.2. 采用Model方式容易解決項目的集成問題（兩個不同模塊組件訪問同一張表的情況）
2. 架構的結構化能力
事務腳本直接訪問到表。換句話說，其架構只有Service + Database Table，這樣的架構下Database Table可以說就是我們的模型。
這里看看在邏輯設計上Domain Model對于架構影響
A. Service， Model和Repository，model的重建和關聯交由Repository完成，單個數據邏輯交給Model（支持泛化）
B. 測試的好處
3. 分析和設計的統一
溝通的問題，客戶關注于其業務，分析的模型接近于客戶需求，設計也采用model的方式，避免分析和設計的割裂。有助于IT間，IT和BA（客戶）間的溝通
4. 其它好處
4.1.采用Domain Model可以屏蔽持久化信息。持久化設計的表設計是和DBA相關的，DBA對于表設計有權力的，采用Model可以有效隔離各自工作；
4.2.Model可以通過很多的手段透明的解決性能問題，而采用表做模型導致容易導致性能問題，當然不是沒有辦法解決，一種是通過DataSet的方式，但這樣的切換成本較高。
應用Domain的體系結構
如前所述，邏輯設計上Domain Model的實施使得架構分為Service，Model和Repository；其中Model的持久化，重建和關聯交由Repository完成；而單數據邏輯（依賴自身數據信息以及關聯數據）則歸于Model（支持泛化）；Service則關注于任務處理，相當于一個macro flow，包括了多個model處理，以及其它服務的調用。
以下是示意圖：
Domain Service | Repository
Domain Object |
Repository和Dao
Repository是一種特殊的Service，不做任務處理；而是提供Model的持久化，重建和查詢工作。由于企業應用大都通過數據庫實現持久化，因而Repository和傳統的Dao間的集成設計就非常重要。
已知的有三種設計方式：
1. 兩個接口兩個實現類。Repository和Dao各自獨立接口，而通過Repository實現類轉發請求給Dao實現類。
這種方式雖然正統，但是維護成本太高；一次更新最多要改四處地方。
2. 兩個接口一個實現類。Repository和Dao各自獨立接口，一個實現類同時實現兩個接口。
這種方式就大大簡化維護成本；一次更新最多只改一個接口和一個實現類。
3. 兩個接口一個實現類。與上面不同是，Dao接口繼承Repository接口，一個實現類實現Dao接口。
這種方式的維護成本和上一種差不多，但是當接口方法在這個兩個接口間流動時，可以通過開發工具完成。
另外Dao實現類本身也是工作中開發維護成本較高的一部分，可以通過代碼生成降低開發成本，更多資料可以參考ibatis。