在领域模型的概念里，两种定义方式。

方式1 ： 失血模型、贫血模型、充血模型、涨血模型 四种概念。

方式2：贫血模型、充血模型 两个概念。

这里以 方式2做阐述。 这里认为：过多的概念并不能支持好的代码的产出，从简单的概念里阐述好的行为和不好的行为即可。

贫血模型vs充血模型

贫血模型：也称贫血领域对象，指仅用作数据载体，而没有行为和动作的领域对象。

充血模型：也称充血领域对象，同时定义数据和行为的领域对象。

个人理解：

贫血模型：提供基本的数据支持，不包含实际业务逻辑。

充血模型：提供数据支持，同时提供具体业务逻辑支持。

举例说明

如：计算学生的BMI。

贫血模型：

class Student {
    Long id;
    double height;
    double weight;

    public double getHeight() {...}
	public double getWeight() {...}
};

class ClassService {
    public double getBMIByStudentId(long id) {...}
};

充血模型：

class Student {
    Long id;
    double height;
    double weight;

    public double getHeight() {...}
	public double getWeight() {...}
    public double getBMI() {...}
}

对比两者代码，容易发现：

1. 贫血模型的业务，放在Service中。
2. 充血模型的业务，放在DP中。

从业务重用上看：

充血模型，业务重用的最小个体是DP。

贫血模型，业务重用的最小个体为Service。如果Service包含其他业务就会导致不必要的依赖。

面向对象的角度

从OO的角度去审视贫血模型和充血模型，会发现：

贫血模型的本质是在一堆数据上建立一个一个业务流程，是一个面向过程的实现方式。

充血模型既有数据也有对应的行为，这是面向对象的。

如何选择

我们知道充血模型即要抽象属性，也要抽象行为；会比贫血模型更难设计。所以在选用时也有相应的偏好，或者有结合使用的情况。

如果业务只是简单的CRUD，或者CRUD可以解决90%的业务情况。推荐使用贫血模型。其实大量的项目都是这样的简单项目。

但是如果在做复杂的项目，拥有复杂的业务时，我们就需要使用充血模型；

DDD是基于好的抽象，宁愿不抽象，也不要固执的做出不合理的抽象。