简单域驱动设计中的Anemic域模型与域模型 [英] Anemic Domain Model's vs. Domain Model in a simple domain driven design

问题描述

我最近在 贫血域模型模式引起了我的注意。当我读完这篇文章时，我发现Anemic Domain Model描述适用于我从事和构建的许多项目。我从来没有认为这是一个糟糕的设计决定，因为它很自然。我认为，在域模型重量轻且不十分复杂的情况下，Anemic域模型绰号非常合适。为什么要在域模型中添加不必要的复杂性，以免 Anemic域模型的标题不能恰当地描述您的代码？

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?

问题：在什么时候将更多的代码复杂性填充到服务/应用程序层变得不正确，而有利于暴露实体对象的复杂性？我全力以赴在实体上拥有总计属性，以便在内部可以计算总计的值。我并不是要让Entity与其他各种窗口小部件直接通信以确定其属性之一的结果。那么，贫血域模型的概念是反模式还是关注点分离？

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.

推荐答案

关键问题是问为什么域模型贫乏？

• 几乎完全没有业务逻辑，例如在主要由 CRUD屏幕？


• 面向服务的体系结构，其中的域对象实际上是简单结构 数据传输对象？


• 出于政治或实际考虑，例如代码所有权或向前/向后兼容性


• 是否以其他面向对象的语言应用过程/关系设计？

• Near-total absence of business logic, as in an application which is primarily an assemblage of CRUD screens?
• Service-oriented architecture in which the 'domain objects' are in fact simple structures data transfer objects?
• Political or pragmatic considerations such as code ownership or forward/backward compatibility that excessively impede refactoring?
• Applying procedural/relational design in an otherwise object-oriented language?

无论如何，如果我要选择一条简单的规则从域模型逻辑和服务逻辑之间的边界来看，在域内与相关对象的交互很好，而访问外部世界（用户界面，Web服务等）可能不属于域模型。

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.

这篇关于简单域驱动设计中的Anemic域模型与域模型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！