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

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

概念依賴

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

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