贫血领域模型一个明显的特征是：它仅仅是看上去和领域模型一样，都是对象，都以领域空间中定
义的名词命名，这些对象通过实际领域模型中丰富的关系和结构相互关联。但是观察模型所持有的
业务逻辑时会发现，贫血模型中除了大量 getter 和 setter，几乎没有其他业务逻辑。
当然，在使用贫血领域模型时，那些数据模型会从一系列服务对象（传统上称为业务层）中使用，这些
服务对象会捕获所有领域或业务逻辑。业务层位于数据模型层之上，并仅将数据模型作为数据使用。
贫血领域模型只是一种过程化的风格设计。因为缺乏行为（方法），贫血实体对象不是真正的对象。它
们只有数据属性，因此也不是面向对象的设计。通过将所有行为放到服务对象（业务层）中，最终得到
的是面条式代码或事务性脚本，因此失去了领域模型提供的优势。
无论如何，如果微服务或限界上下文非常简单（如 CRUD 服务），使用表现为只有数据属性的实体对
象的贫血领域模型或许足够了，此时可能不值得实现更复杂的 DDD 模式。这种情况下，它将是一个简
单的持久化模型，因为已经有意为 CRUD 这个目标创建了只有数据的实体。
因此微服务架构完美适用于依赖每个限界上下文的多重架构方法。例如在 eShopOonContainers 中，订
单微服务实现了 DDD 模式，但简单的 CRUD 服务，如目录微服务就没有用到。
有人说贫血领域模型是一个反模式。这其实取决于要实现什么。如果正在创建的微服务足够简单（如
CRUD 服务），遵循贫血领域模型就不是反模式。但如果要应对微服务的领域有很多不断变化的业务规
则并且很复杂，贫血领域模型对这样的微服务或限界上下文可能就是一个反模式。这种情况下，将其设
计为包含数据和行为以及实现额外的 DDD 模式（聚合，值对象等等）的富模型，或许对微服务的长期
成功有更大好处。