1、以业务层（领域模型）为核心
2、高内聚、低耦合
【特点】
1、将DAO接口置于业务层；
2、在数据访问层实现DAO接口，PO服务于DAO接口
【分层】
显示层－业务层－数据访问层（下面简称数据层）
业务层：细分为事务层－操作层－实体层－DAO接口，DAO接口进一步分为读接口和写接口
数据层：DAO实现＋PO
显示层：这个比较简单，用MVC框架，然后调用业务层即可
【业务层与数据层的关系】
数据层服务于业务层，业务层定义数据访问的接口（DAO接口），数据层来实现，数据层的PO是为了持久化的目的设计的，这也是PO唯一的存在价值，PO不属于业务层范畴，不具备反映业务逻辑的职责，它的活动范围被严格限制在数据层之内，换句话说，无论是业务层还是显示层都不能引用PO。
是否设计PO与所使用的持久化技术有关，如果业务实体能够直接拿来持久化，而且性能没有问题，那么就不需要单独设计PO。总之PO属于数据层的实现细节，业务层的设计可以不考虑PO的任何问题，只管提DAO接口就是了。当然DAO接口只能用业务实体做参数，而不能有PO。
【业务层的设计原则】
事务层：包含事务的业务逻辑。必须定义接口。如果用Spring，则在此层绑定事务
操作层：不包含事务的业务逻辑。必须定义接口
实体层：包含简单的、操作自身和聚合边界内其它实体的业务逻辑。接口定义不是必须的。可变的、不稳定的业务逻辑通过在操作层、事务层应用策略模式等方式解决。
DAO接口：接口的语义仅限于反映实体的持久化操作，比如create、update、delete、findByXXX，DAO接口不能带有业务语义。不遵守这个原则会造成业务逻辑与数据逻辑的混淆，不符合高内聚的最高原则
【依赖关系】
总的依赖方向：显示层->业务层<-数据层
显示层可以引用：事务层、操作层、实体层和读的DAO接口，不可以引用写的DAO接口
事务层可以引用：事务层、操作层、实体层和读写的DAO接口
操作层可以引用：操作层、读的DAO接口和实体层
实体层不可以引用其它任何层的接口，包括DAO，实体的操作限于其聚合边界内