与 这个讨论 有点间接关系，我经常被问到是否相信“丰富”的领域模型或“贫血”的领域模型。我想我对这些术语的真正含义相当无知，因为我从未看到过这两个术语的正式定义。
如果我们说的“贫血”的领域模型是指“永远”不在我们的对象模型上编写任何业务逻辑，而如果我们说的“丰富”的领域模型是指“尽可能”在领域模型上编写业务逻辑，那么我当然不相信任何一种方法。但这些似乎是夸张的；我不认为任何人会遵循这两种极端。
那么我是如何决定哪些实现业务逻辑的方法可能属于领域模型呢？
在这里，我是基于这样的理解：领域模型（实体类）是我代码库中最可重用的类。因此，我不想在那里放置任何依赖于任何状态或协作类的逻辑/除了
- 领域模型中持有的状态（持久属性），以及
- 其他领域模型类。
特别是，我永远不会在我的实体类中编写调用外部服务、访问数据库或调用 EJB/Seam/Spring 组件的代码。我希望我的领域模型是/完全自包含的！
所以，任何时候当你发现自己希望实体支持注入，或者发现自己在一个实体方法中编写 JNDI 查找时，请考虑你的领域模型已不再是自包含的，将在不同的执行环境中变得不太可重用。
我并不是说“违背”这些“规则”是/wrong/的。在设计中没有对错之分。但我认为拥有一个自包含的领域模型有很大的价值，我从未见过一个不实用的场景。
