最近在對之前做過的一個項目進行二期修改。鑒于之前典型的貧血結構，以及Controller--->Service--->DAO模式讓代碼壓力都集中在service層的情況。在參考了Banq寫的幾篇對象職責和Domain Event的文章后，我也試著搗鼓了一下新的分層模式。貼出來和大家討論，歡迎拍磚！
【1】層次劃分：
①控制層：數據映射、控制轉向、業務調用
②業務層：從用戶角度出發，看到的系統可以提供的功能接口
③實體層：包含了數據與行為的實體對象
④服務層：從程序內部角度出發，為了完成業務而劃分出來的細粒度功能模塊
⑤倉儲層：對象的構建、緩存、持久化
上面我的說法可能不是很規范,因為
DDD也沒有仔細的研究，可能大家會對業務和服務層的直至有所疑惑：這里我的想法就是一個從用戶角度出發的業務操作，對應到程序內部可能會被劃分成多個細粒度的程序操作。
【2】協作關系：
①控制層與業務層：
※控制層提供業務層所需的原始，未經封裝的數據
※控制層提供業務調用
※業務層返回給控制層業務出來結果，由控制層決定轉向
②業務層與實體層：
※業務層在必要時(new，edit，delete等一系列命令操作)，從倉儲中加載對象
※業務層向實體層對象發出事件通知
※業務層接收實體的行為反饋
③實體與服務層：
※實體通過“服務注冊”的方式，讓實體具有“自我數據操縱”的能力
※實體接受到業務層的事件通知后，廣播給注冊的服務提供者
※服務層為需要提供服務的實體提供相應的操作功能
※實體層中包含了實體邏輯(可以自己處理而不需要依賴其他模塊、層次)
※服務層中包含了服務邏輯(無法通過一個對象自身完成，涉及到其它對象)
④業務與服務層：
※當業務要求是查詢要求，或者與特點對象無關時，業務層直接請求服務層
※服務層可以看成是對業務層請求的內部實現
⑤服務層與倉儲層：
※倉儲層的對象實體可以是：新建，緩存，從持久化介質中加載
※倉儲層中包含了構建對象的Builder，否則構建和校驗
※倉儲層中包含了對象的緩存和緩存操作
※倉儲層中包含了對持久層的訪問
⑥實體與倉儲層：
※倉儲層構建的最終對象就是實體，倉儲是實體的來源，也是實體最終的去向
下面分為兩只情況來闡述協作流程：
【3】增刪改請求的協作流程
【4】查詢請求的協作流程
【5】疑惑與擔憂
①這種分層是否合理？因為我想讓對象通過事件來消除和服務層的耦合？
②這種把命令、查詢分開來對待的做法會不會令日后的邏輯變得分散而難以維護？
③在倉儲的構建過程中，有可能需要調用服務層邏輯，會不會造成服務<--->倉儲的雙向依賴而耦合？
寫了很多~~~也有勞大家費心看看。實在不想再回到貧血模型的日子啦
-------------------------------------------------------------
生活就像打牌，不是要抓一手好牌，而是要盡力打好一手爛牌。
posted on 2010-03-23 17:05
Paul Lin 閱讀(1582)
評論(0) 編輯 收藏 所屬分類:
架構與性能