training —— Refactoring from Anemic Domain Model Towards a Rich One （overview）

Refactoring from Anemic Domain Model Towards a Rich One

 

贫血模型：

 

数据 & 操作 分离

数据 ： public getters/ setters

操作： stateless services =》 业务逻辑

 

缺点：

1.  methods works on some data =》可发现性； discoverability：

2. 导致 代码重复：data & operation分离 =》maybe 没意识到已存在同样的功能，找不到 实现的位置 =》代码重复

3. 缺少 封装：（most important : ）

plus

不符合 面向对象（modle & operation =》together）

 

 

 

 

　　

 

封装 —— 目的：

不是 隐藏信息

不是 数据&操作 的绑定

 

是 保护数据的完整性

1. 阻止 invalid() & inconsisitent

2. 副产品 =》 信息隐藏；数据&操作 的绑定

 

 

 

 

 

 

 

 

封装  =》复杂度 降低

1. 开发速度，

2. bug数量，

3. 业务需求的相应能力

 

贫血模型 always 表示 缺少 封装（=》 maitain it's invariants: 定义，限制）

 

=》invariants 从 data 移动到了service

=》每个操作 都需要 注意 invariants，否则导致数据 inconsistent

 

 

 

 

 

 

 

贫血模型 —— 优点

1. 符合 直觉

2. 实现 简单

 

 

 =》如何选择 贫血模型？ rich domain model？

1. 项目 的 持续时间；

2. 项目 的 规模大小；

3. 仅限于 项目 的 边界上下文；

 

 

 

 

 

函数编程 & 贫血模型：

 

 

函数编程 的共同点：

1. 可变的 数据结构

2. 针对数据的操作是分开的

 

 

 

 

 class & operate: 分离

 

函数编程 

不意味着 一定会有维护问题，尽管使用的 贫血模型进行编程, 因为 存在 不变性问题

（很容易 损害class的内部状态 =》 因为 可以自由改变状态，而无需 注意class的invriant）

 

 

 

封装 仅存在于 需要修改数据的时候 =》确保 数据修改后 的一致性

 

 

主要保证class的immutable =》无需顾虑 贫血模型 带来的损害后果

 

=》函数模型 & 贫血模型 ：可以很好的合作

 

 

 

 

一旦创建，不可修改 =》immutability =》内部状态是稳定的 =》无需 封装

 

 

贫血模型 —— 操作的不可见性

通过 约定 减轻此负面作用

 

 

 

 

总结：