2004年建模專家Eric Evans發(fā)表了他影響力的書籍：Domain-Driven Design –Tackling Complexity in the Heart of Software（中文譯名：領(lǐng)域驅(qū)動設(shè)計 2006年3月清華出版社譯本，或稱 Domain Driven-Design architecture [Evans DDD]）。
Martin Fowler作序說；“希望本書是一本非常有影響力的書籍,....... Eric最值得我尊敬的一個方面是他敢于討論還未取得成功的事情”，其實，時值今年2006年，DDD開發(fā)框架已經(jīng)層出不窮（如RoR、RIFE、JdonFramework等），我們項目軟件包結(jié)構(gòu)都變成了這樣：xxx.model;xxx.service，DDD思想已經(jīng)遍地開花，不能再說不成功了。
DDD是告訴我們?nèi)绾巫龊脴I(yè)務(wù)層！并以領(lǐng)域驅(qū)動設(shè)計思想來選擇和合適的框架，本文以基于JdonFramework開發(fā)的JiveJdon3.0說明DDD方法的實戰(zhàn)應(yīng)用。
首先必須認識到：領(lǐng)域建模是一種藝術(shù)的技術(shù)，不是數(shù)學(xué)的技術(shù)，它是用來解決復(fù)雜軟件快速應(yīng)付變化的解決之道（快速適應(yīng)需求變化的軟件復(fù)用）。
我們知道軟件的產(chǎn)生過程是：分析、設(shè)計、編程、測試、部署。過去，分析領(lǐng)域和軟件設(shè)計是分裂的，分析人員從領(lǐng)域中收集基本概念；而設(shè)計必須指明一組能北項目中適應(yīng)編程工具構(gòu)造的組件，這些組件必須能夠在目標(biāo)環(huán)境中有效執(zhí)行，并能夠正確解決應(yīng)用程序出現(xiàn)的問題。 模型驅(qū)動設(shè)計(Model-Driven Design)拋棄了分裂分析模型與設(shè)計的做法，使用單一的模型來滿足這兩方面的要求。這就是領(lǐng)域模型。
單一的領(lǐng)域模型同時滿足分析原型和軟件設(shè)計，如果一個模型實現(xiàn)時不實用，重新尋找新模型。如果模型沒有忠實表達領(lǐng)域關(guān)鍵概念時，也必須重新尋找新的模型。 建模和設(shè)計成為單個迭代循環(huán)。將領(lǐng)域模型和設(shè)計緊密聯(lián)系。因此，建模專家必須懂設(shè)計，會編程。
分層架構(gòu)
最初層次只分為三層：表現(xiàn)層、業(yè)務(wù)層和持久層；DDD其實告訴我們?nèi)绾巫寣崿F(xiàn)業(yè)務(wù)層！
一位網(wǎng)友曾經(jīng)請教層次的職責(zé)，對服務(wù)Service提出疑問。根據(jù)Eric的理論，業(yè)務(wù)層將細分為兩個層次：應(yīng)用層和領(lǐng)域?qū)?。它們的定義是：應(yīng)用層：定義軟件可以完成的工作，并且指揮具有豐富含義的領(lǐng)域?qū)ο髞斫鉀Q問題，保持精練；不包括業(yè)務(wù)規(guī)則或知識，無業(yè)務(wù)情況的狀態(tài)； 領(lǐng)域?qū)樱贺撠?zé)表示業(yè)務(wù)概念、業(yè)務(wù)狀態(tài)的信息和業(yè)務(wù)規(guī)則，是業(yè)務(wù)軟件核心。
層次之間必須清晰分離，每個層都是內(nèi)聚的，并且只依賴它的下層，為了實現(xiàn)各層的解耦，Ioc模式和Ioc容器是目前的選擇，JdonFramework使用基于PicoContainer的Ioc容器實現(xiàn)了各層的松耦合；
Eric特別指出：那種將業(yè)務(wù)邏輯交由業(yè)務(wù)界面處理的快速UI方式是旁門左道。希望象C/S結(jié)構(gòu)那樣可視化拖拖圖形就完成的軟件開發(fā)是一種錯誤的方向，開發(fā)時快速，難于維護和擴展，雖然使用J2EE技術(shù)，其實是一種偽多層技術(shù)?？上В泻芏鄧嗽诏偪耖_發(fā)這類工具，大有不撞南墻不低頭之勢，并且瘋狂誤導(dǎo)很多非專業(yè)人士，可悲可嘆！如果對這段言論持不同意見，建議你購買"領(lǐng)域驅(qū)動設(shè)計"這本譯書，見P53頁。
領(lǐng)域模型種類
傳統(tǒng)模型分為兩種：實體（Entity）和值對象（Value Object），現(xiàn)在服務(wù)（Service）成為第三種模型元素。
實體（Entity）定義：通過一系列連續(xù)性（continuity）和標(biāo)識（identity ID）來定義；個人認為它和分析領(lǐng)域的四色原型中的PPT原型非常類似，可以看成是PPT原型延續(xù)。
Martin Fowler作序說；“希望本書是一本非常有影響力的書籍,....... Eric最值得我尊敬的一個方面是他敢于討論還未取得成功的事情”，其實，時值今年2006年，DDD開發(fā)框架已經(jīng)層出不窮（如RoR、RIFE、JdonFramework等），我們項目軟件包結(jié)構(gòu)都變成了這樣：xxx.model;xxx.service，DDD思想已經(jīng)遍地開花，不能再說不成功了。
DDD是告訴我們?nèi)绾巫龊脴I(yè)務(wù)層！并以領(lǐng)域驅(qū)動設(shè)計思想來選擇和合適的框架，本文以基于JdonFramework開發(fā)的JiveJdon3.0說明DDD方法的實戰(zhàn)應(yīng)用。
首先必須認識到：領(lǐng)域建模是一種藝術(shù)的技術(shù)，不是數(shù)學(xué)的技術(shù)，它是用來解決復(fù)雜軟件快速應(yīng)付變化的解決之道（快速適應(yīng)需求變化的軟件復(fù)用）。
我們知道軟件的產(chǎn)生過程是：分析、設(shè)計、編程、測試、部署。過去，分析領(lǐng)域和軟件設(shè)計是分裂的，分析人員從領(lǐng)域中收集基本概念；而設(shè)計必須指明一組能北項目中適應(yīng)編程工具構(gòu)造的組件，這些組件必須能夠在目標(biāo)環(huán)境中有效執(zhí)行，并能夠正確解決應(yīng)用程序出現(xiàn)的問題。 模型驅(qū)動設(shè)計(Model-Driven Design)拋棄了分裂分析模型與設(shè)計的做法，使用單一的模型來滿足這兩方面的要求。這就是領(lǐng)域模型。
單一的領(lǐng)域模型同時滿足分析原型和軟件設(shè)計，如果一個模型實現(xiàn)時不實用，重新尋找新模型。如果模型沒有忠實表達領(lǐng)域關(guān)鍵概念時，也必須重新尋找新的模型。 建模和設(shè)計成為單個迭代循環(huán)。將領(lǐng)域模型和設(shè)計緊密聯(lián)系。因此，建模專家必須懂設(shè)計，會編程。
分層架構(gòu)
最初層次只分為三層：表現(xiàn)層、業(yè)務(wù)層和持久層；DDD其實告訴我們?nèi)绾巫寣崿F(xiàn)業(yè)務(wù)層！
一位網(wǎng)友曾經(jīng)請教層次的職責(zé)，對服務(wù)Service提出疑問。根據(jù)Eric的理論，業(yè)務(wù)層將細分為兩個層次：應(yīng)用層和領(lǐng)域?qū)?。它們的定義是：應(yīng)用層：定義軟件可以完成的工作，并且指揮具有豐富含義的領(lǐng)域?qū)ο髞斫鉀Q問題，保持精練；不包括業(yè)務(wù)規(guī)則或知識，無業(yè)務(wù)情況的狀態(tài)； 領(lǐng)域?qū)樱贺撠?zé)表示業(yè)務(wù)概念、業(yè)務(wù)狀態(tài)的信息和業(yè)務(wù)規(guī)則，是業(yè)務(wù)軟件核心。
層次之間必須清晰分離，每個層都是內(nèi)聚的，并且只依賴它的下層，為了實現(xiàn)各層的解耦，Ioc模式和Ioc容器是目前的選擇，JdonFramework使用基于PicoContainer的Ioc容器實現(xiàn)了各層的松耦合；
Eric特別指出：那種將業(yè)務(wù)邏輯交由業(yè)務(wù)界面處理的快速UI方式是旁門左道。希望象C/S結(jié)構(gòu)那樣可視化拖拖圖形就完成的軟件開發(fā)是一種錯誤的方向，開發(fā)時快速，難于維護和擴展，雖然使用J2EE技術(shù)，其實是一種偽多層技術(shù)?？上В泻芏鄧嗽诏偪耖_發(fā)這類工具，大有不撞南墻不低頭之勢，并且瘋狂誤導(dǎo)很多非專業(yè)人士，可悲可嘆！如果對這段言論持不同意見，建議你購買"領(lǐng)域驅(qū)動設(shè)計"這本譯書，見P53頁。
領(lǐng)域模型種類
傳統(tǒng)模型分為兩種：實體（Entity）和值對象（Value Object），現(xiàn)在服務(wù)（Service）成為第三種模型元素。
實體（Entity）定義：通過一系列連續(xù)性（continuity）和標(biāo)識（identity ID）來定義；個人認為它和分析領(lǐng)域的四色原型中的PPT原型非常類似，可以看成是PPT原型延續(xù)。