Martin Fowler作序說；“希望本書是一本非常有影響力的書籍,....... Eric最值得我尊敬的一個方面是他敢于討論還未取得成功的事情”，其實，時值今年2006年，DDD開發(fā)框架已經(jīng)層出不窮（如RoR、RIFE、JdonFramework等），我們項目軟件包結構都變成了這樣：xxx.model;xxx.service，DDD思想已經(jīng)遍地開花，不能再說不成功了。

　　DDD是告訴我們?nèi)绾巫龊脴I(yè)務層！并以領域驅動設計思想來選擇和合適的框架，以基于JdonFramework開發(fā)的JiveJdon3.0說明DDD方法的實戰(zhàn)應用。

　　首先必須認識到：領域建模是一種藝術的技術，不是數(shù)學的技術，它是用來解決復雜軟件快速應付變化的解決之道（快速適應需求變化的軟件復用）。

　　我們知道軟件的產(chǎn)生過程是：分析、設計、編程、測試、部署。過去，分析領域和軟件設計是分裂的，分析人員從領域中收集基本概念；而設計必須指明一組能北項目中適應編程工具構造的組件，這些組件必須能夠在目標環(huán)境中有效執(zhí)行，并能夠正確解決應用程序出現(xiàn)的問題。 模型驅動設計(Model-Driven Design)拋棄了分裂分析模型與設計的做法，使用單一的模型來滿足這兩方面的要求。這就是領域模型。

　　單一的領域模型同時滿足分析原型和軟件設計，如果一個模型實現(xiàn)時不實用，重新尋找新模型。如果模型沒有忠實表達領域關鍵概念時，也必須重新尋找新的模型。 建模和設計成為單個迭代循環(huán)。將領域模型和設計緊密聯(lián)系。因此，建模專家必須懂設計，會編程。

　　分層架構

　　最初層次只分為三層：表現(xiàn)層、業(yè)務層和持久層；DDD其實告訴我們?nèi)绾巫寣崿F(xiàn)業(yè)務層！

　　一位網(wǎng)友曾經(jīng)請教層次的職責，對服務Service提出疑問。根據(jù)Eric的理論，業(yè)務層將細分為兩個層次：應用層和領域層。它們的定義是：應用層：定義軟件可以完成的工作，并且指揮具有豐富含義的領域對象來解決問題，保持精練；不包括業(yè)務規(guī)則或知識，無業(yè)務情況的狀態(tài)； 領域層：負責表示業(yè)務概念、業(yè)務狀態(tài)的信息和業(yè)務規(guī)則，是業(yè)務軟件核心。

　　層次之間必須清晰分離，每個層都是內(nèi)聚的，并且只依賴它的下層，為了實現(xiàn)各層的最大解耦，Ioc模式和Ioc容器是目前最好的選擇，JdonFramework使用基于PicoContainer的Ioc容器實現(xiàn)了各層的松耦合；

　　Eric特別指出：那種將業(yè)務邏輯交由業(yè)務界面處理的快速UI方式是旁門左道。希望象C/S結構那樣可視化拖拖圖形就完成的軟件開發(fā)是一種錯誤的方向，開發(fā)時快速，難于維護和擴展，雖然使用J2EE技術，其實是一種偽多層技術。可惜，有很多國人在瘋狂開發(fā)這類工具，大有不撞南墻不低頭之勢，并且瘋狂誤導很多非專業(yè)人士，可悲可嘆！如果對這段言論持不同意見，建議你購買"領域驅動設計"這本譯書，見P53頁。

　　領域模型種類

　　傳統(tǒng)模型分為兩種：實體（Entity）和值對象（Value Object），現(xiàn)在服務（Service）成為第三種模型元素。

　　實體（Entity）定義：通過一系列連續(xù)性（continuity）和標識（identity　ID）來定義；個人認為它和分析領域的四色原型中的PPT原型非常類似，可以看成是PPT原型延續(xù)。