一直想系統(tǒng)的整理一下自己有關Domain Model實踐的嘗試。但總覺得自己的想法還不夠系統(tǒng)而作罷。
然而從另一方面看“系統(tǒng)的東西”也許永遠做不到，失去了目標的生活該會多乏味。
因此我決定將自己有關Domain Model設計的有關實踐和思考和盤托出，也算是拋磚引玉。歡迎大家
參與討論，遇到同你的觀點相左的地方，希望能以包容的態(tài)度來面對，我們是朝同一方向走的伙伴而不是
相互對視的敵人。：）

在深入討論之前我先拋出一些原則和概念，最后你會看到這些概念和原則的威力。
1.按照概念依賴的原則來組織業(yè)務層。
2.將業(yè)務活動（業(yè)務流程）建模成類。
3.用業(yè)務活動（業(yè)務流程）作為關聯(lián)整個業(yè)務層各種對象的骨架。
4.在業(yè)務活動中鑿出擴展點，使用不同接口分離不同性質業(yè)務對象。
5.將對象的存儲理解為業(yè)務層概念。
......

概念依賴

這是我認為能否得到良好業(yè)務層最重要的概念。
在我系統(tǒng)框架設計將要完成，開始涉及業(yè)務層設計時，我腦袋一片空白，書上，大家討論的大多是整個系統(tǒng)的結構從UI層
到服務層到數據訪問層到數據庫。到底業(yè)務層該如何組織？Martin Fowler的POEAA的書中沒有回答。找到的相關
書籍也都過于空泛。Martin Fowler的分析模式有些用處，但不夠系統(tǒng)。透過Martin fowler網站，我拿到了
Domain Driven Design的發(fā)行前版本。該書給了我很大的啟示。其中的要點有：
關于關聯(lián)：
1.Imposing a traversal direction (強制一個關聯(lián)的導航方向)
......
關于Responsibility Layers（業(yè)務職責層）的劃分：
作者給出了三個指導原則：Conceptual dependency.(概念依賴)為其中一項。
書中給出的描述的是業(yè)務職責層上層的對象需要通過下層對象才能在概念上完整，
相反下層對象則可獨立于上層對象存在含義。這樣天然的下層對象相對于上層對象
會更穩(wěn)定。并且在今后演變的過程中，使同擴展的方式來完善系統(tǒng)，而不是改變對象
的方式。
通過實踐，我覺得這條原則可以應用在任何兩個有關聯(lián)的業(yè)務對象上。通常可以通過
概念依賴先建立一個導航方向。這能夠滿足大多數的需求。當確實需要反向導航時，
只要理由充分可以隨時加上，并且如果先前將這兩個對象放入不同包中，這時需要
將他們合并到同一個包中。
我見過一個不好的設計。Customer具有很多Flag分別標記該客戶是否掛失，凍結，注銷等等。
通常叫做客戶狀態(tài),然而這是不對的，這違背了單一職責原則。事實上除了注銷外
掛失和凍結都不應該算作Customer的本質屬性。相反我把他們看作某種約束，進而把掛失看作
一種協(xié)議.....因為Customer的概念可以不依賴于掛失和凍結的概念，相反掛失和凍結卻要依賴
Customer的概念，應為這是他們動作的主體。
同樣的一開始就讓Customer有GetAccount的方法同樣不好。因為Customer的概念確實不依賴Account
XXXAccount卻可以有Customer的屬性，Account在概念上依賴Customer。

安徽新華電腦學校專業(yè)職業(yè)規(guī)劃師為你提供更多幫助【在線咨詢】