DDD中的 充血模型 和 贫血模型

领域驱动设计，关键是要做领域建模，领域建模的结果叫领域模型。领域模型还有一个名字叫充血模型，以与贫血模型这个名称做对应。

贫血领域模型的基本特征是：

• 它第一眼看起来还真像这么回事儿。项目中有许多对象，它们的命名都是根据领域来的。
• 对象之间有着丰富的连接方式，和真正的领域模型非常相似。
• 但当你检视这些对象的行为时，会发现它们基本上没有任何行为，仅仅是一堆getter/setter。

这些对象在设计之初就被定义为只能包含数据，不能加入领域逻辑；逻辑要全部写入一组叫Service的对象中；而Service则构建在领域模型之上，需要使用这些模型来传递数据。

面向对象设计主张将数据和行为绑定在一起，而贫血领域模型则更像是一种面向过程设计。

贫血领域模型的根本问题是：

• 它引入了领域模型设计的所有成本，却没有带来任何好处。
• 最主要的成本是将对象映射到数据库中，从而产生了一个O/R（对象关系）映射层。

如果将所有行为都写入到Service对象，那最终你会得到一组事务处理脚本，从而错过了领域模型带来的好处。所以充血模型应用层要做薄，领域层做厚。

贫血模型的优点：简单

• 对于只有少量业务逻辑的应用来说，使用起来非常自然；
• 开发迅速，易于理解；

注意：也不能完全排斥这种方式。

贫血模型的缺点：无法良好的应对复杂逻辑

• 随着业务发展，不断引入新的规则，可维护性变差。比如：和欧洲签订的合同使用另外一个规则...

总结

理论上OOP总是比面向过程编程要有更丰富的语义、更合理的组织、更强的可维护性，看起来应该广泛使用。

但是它更难掌握，其中最大的难关就是“如何设计充血模型”，或者说“如何从复杂的业务中分离出恰到好处且包含语义逻辑行为并放到合适的对象中”。

所以，需要通过团队能力、业务复杂度、业务稳定还是快速试错等因素来决定使用那个模型。