我最近读了一篇关于“的文章贫血域模型模式”引起了我的注意。 当我通读本文时，我发现贫血领域模型描述适用于我参与和构建的许多项目。 我从来不认为这是一个糟糕的设计决定，因为它感觉很自然。 我认为在 域模型 重量轻且不是很复杂的情况下，贫血域模型绰号很合适。 为什么要增加域模型的复杂性，而不必只是让“贫血域模型”的标题不能恰当地描述您的代码？
问题：在什么时候，将更多的代码复杂性填充到服务/应用程序层中会变得不正确，而有利于暴露实体对象的复杂性？ 我完全赞成在实体上拥有“总计”属性，它可以在内部计算出总计的值。 我不赞成让实体直接与各种其他小部件通信以确定其属性之一的结果。 那么，贫血领域模型的概念是一种反模式还是一种良好的关注点分离？ 贫血领域模型这个标题总是一件坏事吗？
只是好奇其他人对这种设计（反）模式的想法是什么。
I recently read a post on "The Anemic Domain Model Pattern" which caught my attention. As I read through this I found that the Anemic Domain Model description applied to many of the projects that I have worked on and built. I never thought of this as a bad design decision as it felt very natural. I thought that in the case where the domain model was light weight and not very complex the Anemic Domain Model moniker fit quite well. Why add complexity to the domain model where it doesn't need to be just so the title of "Anemic Domain Model" doesn't aptly describe your code?
Question: At what point does stuffing more of your code complexities into your service/application layer become in-correct in favor of exposing the complexity off of your entity objects instead? I am all for having a "Total" property on an Entity where it internally can figure out the value for the Total. I am not for making the Entity communicate directly with various other widgetry to determine the outcome of one of it's properties. So is the concept of an Anemic Domain Model an anti-pattern or a good separation of concerns? Is the title Anemic Domain Model always a bad thing?
Just curious what other people's thoughts were on this design (anti)pattern.
发布评论
评论（3）
关键问题是问为什么领域模型贫乏？
简单结构数据传输对象？无论如何，如果我要为域模型逻辑和服务逻辑之间的边界选择一个简单的经验法则，那就是在域内与相关对象进行交互是很好的，同时访问“外部世界”（用户界面、 Web 服务等）可能不属于域模型。
The key question is to ask why is the domain model anemic?
simple structuresdata transfer objects?In any case, if I were to pick a simple rule of thumb for the boundary between domain model logic and service logic, it would be that interacting with related objects is fine within the domain, while accessing the "outside world" (user interface, web services, etc) probably doesn't belong in the domain model.
如果域是轻量级的（即：不复杂），建议的方法是在核心域层中使用简单的 ActiveRecord 类型对象。 通常数据库表和域对象之间是一对一的映射，这里没有太多的“逻辑”。 您的应用程序只是在数据库和 UI 之间整理记录并允许简单的 CRUD 操作。
对于复杂的域，您将构建一个核心域模型，其中一些对象最终映射到数据库表，而有些对象可能不会映射到数据库表，并且除了纯数据之外还表示域中的其他概念。 应用程序的逻辑在适当的时候应该位于对象内部，或者如果需要多个域对象之间的协调，则应位于服务对象内部。
贫乏域模型反模式适用于当您有一个复杂的域，但不是将一些逻辑适当地放入域对象中并将一些逻辑放入服务中，而是将所有（或几乎所有）逻辑放在核心域对象外部。
这里的关键区别在于逻辑的放置位置。 如果您没有太多，显然域对象看起来只不过是简单的数据容器。 如果您确实有复杂的逻辑，不要只是将其全部从域对象中取出，而是将其在核心域对象和域服务之间适当地分开。
If the domain is lightweight (read: not complex), the recommended approach is to use a simple ActiveRecord-type objects in your core domain layer. Usually a one-to-one mapping between DB tables and your domain objects and there isn't a whole lot of "logic" here. Your app is just shuffling records between the database and your UI and allowing simple CRUD operations.
For complex domains, you would build out a core domain model where some of the objects end up mapping to DB tables and some likely do not and represent other concepts in your domain besides just plain data. The logic for the application should be inside the objects when appropriate or within Service objects if it requires the coordination between multiple domain objects.
The Anemic Domain Model anti-pattern applies to when you have a complex domain but instead of appropriately putting some logic in the domain objects and some logic in services, you put ALL (or nearly all) the logic external to your core domain objects.
The key difference here is where you put the logic. If you don't have much, obviously the domain objects will look like nothing more than simple data containers. If you do have complicated logic, don't just pull it ALL out of the domain objects but rather separate it appropriately between the core domain objects and domain services.
日安！
如果将逻辑放在域对象之外，您就完全失去了主要的 OO 概念之一：封装（或数据隐藏）。
AOP 在一定程度上弥补了这一点，但毕竟，面向对象的关键概念之一已经消失了。
问候，
斯特凡
G'day!
If you put the logic outside the domain objects you lose one of the main OO concepts completely: encapsulation (or data hiding).
AOP makes it up to a certain degree, but after all, one of the key concets of object orientation is gone.
Regards,
Stefan