zz 失血模型与充血模型等
(贫血模型)优点是系统的层次结构清楚，各层之间单向依赖，Client->（BusinessFacade）->BusinessLogic->Data Access Object。可见，领域对象几乎只作传输介质之用，不会影响到层次的划分。但该模型的缺点是不够面向对象OOP，领域对象只是作为保存状态或者传递状态使用，它是没有生命的，只有数据没有行为的对象不是真正的对象，在Business Logic里面处理所有的业务逻辑，对于细粒度的逻辑处理，通过增加一层Facade达到门面包装的效果
在使用Spring的时候，通常暗示着你使用了贫血模型，我们把Domain类用来单纯地存储数据，Spring管不着这些类的注入和管理，Spring关心的逻辑层（比如单例的被池化了的Business Logic层）可以被设计成singleton的bean。假使我们这里逆天而行，硬要在Domain类中提供业务逻辑方法，那么我们在使用Spring构造这样的数据bean的时候就遇到许多麻烦，比如：bean之间的引用，可能引起大范围的bean之间的嵌套构造器的调用。
ＤＤＤ的特点
- 分层架构
- 成熟，清晰的分层架构
- 领域对象与世界的业务映射
- 明确的职责划分
复用性 - 领域对象是核心
- 领域对象复用：完整的业务对象描述
- 设计利用：设计基于领域对象而非基于数据库的
适用场合 - 具备复杂业务逻辑的软件开发
- 对设计和开发人员要求较高
- 不适合普通的ＣＵＲＤ操作
- 系统的维护性与扩展性较高
对于ＤＤＤ系统架构的分层
不使用ＤＤＤ思想进行系统设计时，一般会分为３层，如数据层，业务层和表现层，而使用ＤＤＤ这后，分层的方式发生了一些改变，先来看一下
表现层：也叫ＷＥＢ层，ＵＩ层，一般体现出来的是页面的布局，可以用web mvc,web form,win form等去实现
应用层：用来协调应用活动，它不包含业务逻辑，它不保留业务对象的状态，但它保存应用任务的进度状态
领域层：包含领域信息，这是业务软件的核心，它保留业务对象的状态，对业务对象和它们状态的持久化工作委托给基础设施层
基础设施层：是其它层的基础，实现对业务对象的持久化，还对ＷＥＢ层可以引用本层
ＤＤＤ中的几个核心对象
Entities:这不是简单的poco实体，而是具备了业务逻辑的实体
Factories:工厂类，用来生产对象
Respositories:持久化,它本身就是DAO (Data Access Objects) 数据访问对象
Services：服务层，为上层提供了操作的接口，负责对象领域对象进行调试和封装，同时提供了各种形式的服务
但是充血模型容易陷入一个困境，就是封装的层次难以维系。上面订单的例子，在实际开发过程中很难将很多业务逻辑落到模型层，例如订单计算可能需要商品、用户积分等其他模型。除了单个模型，批量业务逻辑也很难实现。
于是从 EJB2 开始倡导使用贫血模型，将业务逻辑封装到 Service 这类专门承载业务逻辑的对象，Order 这类的模型只需要承载数据结构。贫血模型，让面向对象变得非常轻量， Spring 大规模推广开之后尤为明显。
