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的性质。