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 =》内部状态是稳定的 =》无需 封装
贫血模型 —— 操作的不可见性
通过 约定 减轻此负面作用
总结：
