zz 失血模型与充血模型等

失血模型与充血模型 | 三秋

(贫血模型)优点是系统的层次结构清楚，各层之间单向依赖，Client->（BusinessFacade）->BusinessLogic->Data Access Object。可见，领域对象几乎只作传输介质之用，不会影响到层次的划分。但该模型的缺点是不够面向对象OOP，领域对象只是作为保存状态或者传递状态使用，它是没有生命的，只有数据没有行为的对象不是真正的对象，在Business Logic里面处理所有的业务逻辑，对于细粒度的逻辑处理，通过增加一层Facade达到门面包装的效果

在使用Spring的时候，通常暗示着你使用了贫血模型，我们把Domain类用来单纯地存储数据，Spring管不着这些类的注入和管理，Spring关心的逻辑层（比如单例的被池化了的Business Logic层）可以被设计成singleton的bean。假使我们这里逆天而行，硬要在Domain类中提供业务逻辑方法，那么我们在使用Spring构造这样的数据bean的时候就遇到许多麻烦，比如：bean之间的引用，可能引起大范围的bean之间的嵌套构造器的调用。

DDD~概念中的DDD - 张占岭 - 博客园

ＤＤＤ的特点

• 分层架构
• 成熟，清晰的分层架构
• 领域对象与世界的业务映射
• 明确的职责划分
  
  复用性
• 领域对象是核心
• 领域对象复用：完整的业务对象描述
• 设计利用：设计基于领域对象而非基于数据库的
  
  适用场合
• 具备复杂业务逻辑的软件开发
• 对设计和开发人员要求较高
• 不适合普通的ＣＵＲＤ操作
• 系统的维护性与扩展性较高

对于ＤＤＤ系统架构的分层

不使用ＤＤＤ思想进行系统设计时，一般会分为３层，如数据层，业务层和表现层，而使用ＤＤＤ这后，分层的方式发生了一些改变，先来看一下

表现层：也叫ＷＥＢ层，ＵＩ层，一般体现出来的是页面的布局，可以用web mvc,web form,win form等去实现

应用层：用来协调应用活动，它不包含业务逻辑，它不保留业务对象的状态，但它保存应用任务的进度状态

领域层：包含领域信息，这是业务软件的核心，它保留业务对象的状态，对业务对象和它们状态的持久化工作委托给基础设施层

基础设施层：是其它层的基础，实现对业务对象的持久化，还对ＷＥＢ层可以引用本层

ＤＤＤ中的几个核心对象

Entities:这不是简单的poco实体，而是具备了业务逻辑的实体

Factories:工厂类，用来生产对象

Respositories:持久化,它本身就是DAO (Data Access Objects) 数据访问对象

Services：服务层，为上层提供了操作的接口，负责对象领域对象进行调试和封装，同时提供了各种形式的服务　　

DDD~领域层 - 张占岭 - 博客园

DDD 就是把面向对象做好 - 知乎

但是充血模型容易陷入一个困境，就是封装的层次难以维系。上面订单的例子，在实际开发过程中很难将很多业务逻辑落到模型层，例如订单计算可能需要商品、用户积分等其他模型。除了单个模型，批量业务逻辑也很难实现。

于是从 EJB2 开始倡导使用贫血模型，将业务逻辑封装到 Service 这类专门承载业务逻辑的对象，Order 这类的模型只需要承载数据结构。贫血模型，让面向对象变得非常轻量， Spring 大规模推广开之后尤为明显。

业务开发常用的基于贫血模型的 MVC 架构违背 OOP 吗？ | 侯瑞哲的博客

领域驱动设计，盒马技术团队这么做