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

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

概念依賴

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

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