目前流行的轻量级Java EE应用的架构基本比较统一，通常会使用Spring作为核心，向上整合MVC框架，向下整合ORM框架。使用Spring的IoC容器来管理个组件之间的依赖关系时，Spring的声明事务将负责业务逻辑层组件的事务管理。当我们决定采用某种架构设计时，我们主要考虑这种架构是否成功地将规范和现实分离了，从而可以提供较好的可扩展性、可修改性。
1.贫血模型
贫血模型是最常用的应用架构，也是最容易理解的架构。所谓贫血，指Domain Object只是单纯的数据类，不包含业务逻辑方法，即每个Domain Object类只包含相关属性，并为每个属性提供基本的setter和getter方法。所有的业务逻辑都由业务逻辑组件实现，这种Domain Object就是所谓的贫血的Domain Object，采用这种Domain Object的架构即所谓的贫血模型。
贫血的Domain Object实际上以数据结构代替了对象。在贫血模型下，业务逻辑对象作为dao组件的门面，封装了全部的业务逻辑方法，web层仅与业务逻辑组件交互即可，无需访问底层的dao对象。贫血模型背离了面向对象的设计思想，所有的Domain Object并不是完整的Java对象。
总结起来，贫血模型存在的缺点：项目需要书写大量的贫血类；Domain Object的业务逻辑得不到体现。由于业务逻辑对象的复杂度大大增加，许多不应该由业务逻辑对象实现的业务逻辑方法，完全由业务逻辑对象实现，从而使业务逻辑对象的实现类变得相当庞大。贫血模型的优点：开发简单、分层清晰、架构明晰且不易混淆，所有的依赖都是单向依赖，解耦优秀。
2.领域对象模型
根据完整的面向对象规则，每个Java类都应该提供其相关的业务方法，所以在系统设计更完备的Domain Object对象，则Domain Object不再是单纯的数据载体，Domain Object也包含了相关的业务逻辑方法，提高重用度，将与Domain Object密切相关的业务方法放在Domain Object对象中实现。DAO对象是变化最小的对象，它们都是进行基本的CRUD操作。
不要在Domain Object中对消息回复完成持久化，如需完成持久化，必须调用DAO组件；一旦调用DAO组件，将造成DAO对象和Domain Object的双向依赖；另外，Domain Object中的业务逻辑方法还需要在业务逻辑组件中代理，才能真正实现持久化。
领域对象模型主要的问题是业务逻辑组件比较复杂：业务逻辑组件继续需要作为DAO组件的门面，而且还需要包装Domain Object里的业务逻辑方法，暴露这些业务逻辑方法，让Action组件可以调用这些方法。
3.合并业务逻辑对象与dao对象
在这种模型下DAO对象不仅包含了各种CRUD方法，而且还包含各种业务逻辑方法。此时的DAO对象，已经完成了业务逻辑对象所有任务，变成了DAO对象和业务逻辑对象混合体。此时，业务逻辑对象依赖Domain Object，既提供了基本的CRUD方法，也提供了相应的业务逻辑方法。DAO对象和业务逻辑对象之间容易形成交叉依赖（可能某个业务逻辑方法的实现，必须依赖于原来的DAO对象）。当DAO对象被取消后，业务逻辑对象取代了DAO对象，因此变成了一个业务逻辑对象依赖多个业务逻辑对象。而每个业务逻辑对象都可能包含需要多个DAO对象协作的业务方法，从而导致业务逻辑对象之间的交叉依赖。
这种模型导致了DAO方法和业务逻辑方法混合在一起，显得职责不够单一，软件分层结构不够清晰。而且使业务逻辑对象之间交叉依赖，容易产生混乱，未能做到彻底的简化。
4.合并业务逻辑对象和domain object
在这种架构下，所有的业务逻辑都应该被放在Domain Object里面，而此时的业务逻辑层不再是传统的业务逻辑层，它仅仅封装了事务和少量逻辑，不再提供任何业务逻辑的实现。在这种设计思路下，业务逻辑层变得非常“薄”，它的功能也变得非常微弱。
在这种设计下，Domain Object必须使用DAO对象直接调用DAO组件的持久化方法，从而使得Domain Object获取容器注入的DAO对象，通过DAO对象完成持久化操作。
这种架构的优点是：业务逻辑对象非常简单，只提供简单的事务操作，业务逻辑对象无须依赖于DAO对象。但这种架构也存在如下缺点：dao对象和Domain Object形成了双向依赖，其复杂的双向依赖会导致很多潜在的问题；业务逻辑层和Domain层的逻辑混淆不清，在实际项目中，极其容易导致架构混乱；由于使用业务逻辑对象提供事物封装特性，业务逻辑层必须对所有的Domain Object的逻辑提供相应的事务封装，因此业务逻辑对象必须重新定义Domain Object实现的业务逻辑，其工作相当繁琐。
5.抛弃业务逻辑层
抛弃业务逻辑层有两种形式：Domain Object彻底取代业务逻辑对象、由控制器直接调用DAO对象。
（1）Domain Object完全取代业务逻辑对象
这种架构设计更加简单，Domain Object与DAO组件形成双向依赖，而web层的控制器直接调用Domain Object的业务逻辑方法。优点是分层少，代码实现简单。缺点是：业务逻辑对象的所有业务逻辑都将在Domain Object中实现，势必引起Domain Object的混乱；Domain Object必须直接传递到web层，从而将持久化API直接传递到web层，因此可能引发意想不到的问题。
（2）控制器完成业务逻辑
在这种模型里，控制器直接调用DAO对象的CRUD方法，通过调用基本的CRUD方法，完成对应的业务逻辑方法。在这种模型下，业务逻辑对象的功能由控制器完成。事务则推迟到控制器中完成，因此对控制器的execute()方法增加事务控制即可。
对于基本的CRUD操作，控制器可直接调用DAO对象方法，省略了业务逻辑对象的封装，这就是这种模式的最大优势。对于业务逻辑简单的项目，这种模型是很好的选择。