Domain Model對于大多數的人來說都不怎么的陌生，Domain Model作為實現業務層的兩種重要方法之一，在PoEAA(企業應用架構模式)中得到Martin Fowler的大力推廣，但個人覺得在Domain Model上的應用并不是那么的理想，這個還得從業務層實現的兩種模式談起，分別為Domain Model和Transaction Script，Domain Model的原則為采用Domain Object的方式來實現業務邏輯，使得業務邏輯得以聚合到對象本身，從本質上提升業務對象的可復用性，其優點就在于提升了業務對象的復用性和代碼的整潔性，缺點則在于實現的難度較高，有一定的學習曲線；Transaction Script則為采用Script的方式編排業務邏輯，其優點在于實現起來簡單，缺點在于代碼中出現較多重復的業務邏輯塊，在業務邏輯一旦變動時需要修改很多地方，降低了業務邏輯的復用性。
其實個人看法是Domain Model為采用OO構成業務層模型的思想，而Transaction Script為采用面向過程構成業務層模型的思想。
從需求分析開始談起，在對需求進行OOA后，產生出系統的業務模型，通過OOD得到業務模型技術體系，那么在Domain Model很簡單的就是將此業務模型技術體系進行Plain Object的實現，從此得到Domain Object，按照這樣的邏輯Transaction Script其實是不應該會出現的，Transaction Script的產生當然是有它的原因的，在復雜的業務場景中需要通過多個Domain Object共同來完成業務功能的實現，而此時在設計不夠良好的Domain Object模型的情況下很難通過Domain Object的協作來做到實現，需要在Domain Object的協作之外處理一些業務邏輯，這個時候Transaction Script就得以出現了，以Script的方式來協作Domain Object并同時補充其中的業務邏輯來完成業務功能的實現，其實這個時候已經可以看到，實現的方式確實是變簡單了，但業務模型則被逐漸的拆離，在Domain Model中則強調Domain Object本身業務邏輯的實現，而業務層則通過引入一層薄Service作為對外的接口來提供業務場景的實現，此時的Service需要做的是調用Domain Object來完成業務場景的實現。
Domain Object對應到業務模型，在結合了持久層來完成相應業務Object的持久，個人覺得ORM的引入在這部分使得Domain Object在需要完成持久的時候更加的優秀，Domain Object中通過注釋標識出需要持久的屬性，當然這是因為ORM工具需要通過這些映射來處理，這樣在對Domain Object作持久操作時可直接的進行，這樣的Domain Object就構成了系統的核心部分，業務模型構成系統的核心模型，這是需求符合體現的關鍵。
至于View Object則由于其簡單性很多時候必須構建，以保持View Layer的單一性以及只是View的性質。