我最近读了一篇有关“ The Anemic Domain Model Pattern”的文章，引起了我的注意。当我读完这篇文章时，我发现Anemic Domain Model描述适用于我从事和构建的许多项目。我从来没有认为这是一个糟糕的设计决定，因为它很自然。我认为在domain model重量轻且不是很复杂的情况下，Anemic Domain Model绰号非常合适。为什么要在域模型中添加不必要的复杂性，以免“ Anemic域模型”的标题不能恰当地描述您的代码？
问题：在什么时候将更多的代码复杂性填充到服务/应用程序层变得不正确，而有利于暴露实体对象的复杂性？我全心全意在实体上拥有“总计”属性，该属性在内部可以计算总计的值。我不是为了使Entity与其他各种窗口小部件直接通信以确定其属性之一的结果。那么，贫血域模型的概念是反模式还是关注点分离？贫血领域模型这个标题总是一件坏事吗？
只是好奇其他人对此设计（反）模式有什么想法。
最佳答案
关键问题是要问域模型为什么贫血？
几乎完全没有业务逻辑，例如在主要是CRUD screens组合的应用程序中？
“域对象”实际上是简单结构data transfer objects的面向服务的体系结构？
政治或实用考虑（例如代码所有权或前向/向后兼容性）过度阻碍重构？
在其他面向对象的语言中应用过程/关系设计？
无论如何，如果我为域模型逻辑和服务逻辑之间的边界选择一个简单的经验法则，那就是在访问“外部世界”（用户界面，网络服务等）可能不属于域模型。