在富域模型和贫血域模型的上下文中，“模型”实际意味着什么？答案

【问题标题】：What does "model" actual mean in the context of rich domain models and anemic domain models?在富域模型和贫血域模型的上下文中，“模型”实际意味着什么？
【发布时间】：2014-05-28 05:08:29
【问题描述】：

如果这个问题已经得到回答，请提前道歉，但我无法找到在这种情况下我真正理解的模型的实际含义的定义。

我听说模型一词仅用于描述持久层、所有特定于域的代码或仅描述域实体。从我读过的内容来看，贫血的领域模型似乎被认为是一件坏事，但具体原因似乎并不完全符合我的要求，我认为这是因为我不知道模型指的是什么在这种情况下。美国这个特定于MVC？

如果它只是指实体，那么仅将保持数据完整性的逻辑放入实体中并将实际使用这些实体的逻辑放入服务类有什么问题？这仍然被认为是贫血吗？如果是这种情况，您如何在不违反单一职责原则的情况下实际实现丰富的领域模型。

答案不需要特定于框架或语言，但如果重要的话，我正在使用 php 和 Symfony2。

提前感谢任何花时间为我提供一些说明的人！

【问题讨论】：

你的意思是这样的：stackoverflow.com/a/5864000/727208?
嗨@teresko。是的，这是我大部分问题的一个很好的答案，谢谢。我仍然模糊的部分是在遵循域驱动设计时域对象和服务之间的区别是什么。哪些职责属于服务，哪些属于领域对象。
服务处理域对象到域对象以及域对象到持久性交互（是否是数据映射器、存储库或/和工作单元取决于您的实现）。域对象处理数据验证并包含业务规则。
我刚刚意识到我的误解是在这种情况下“服务”是什么。我还注意到你是同一个人，他回答了我一半的软件架构相关问题。谢谢@teresko。你绝对是我在 php 社区遇到的最好的人之一。
域服务实现域用例，而域实体和值对象实现概念。

标签： oop symfony model-view-controller domain-driven-design solid-principles

【解决方案1】：

关于服务层和域层的区别，这里有一篇由Martin Fowler 撰写的关于贫血域模型的好文章。

他谈到的反模式是当域模型缺乏域逻辑并且实际上只是 getter 和 setter 的集合时。

这种反模式的根本可怕之处在于它是如此的相反面向对象设计的基本思想；也就是合并数据并一起处理。贫血域模型实际上只是一个程序风格设计。

引用埃里克·埃文斯的话，他说：

应用层[他的名字为服务层]：定义工作软件应该做并且指导富有表现力的领域对象解决问题。

…

领域层（或模型层）：负责表示概念业务，有关业务情况的信息，以及业务规则。 反映业务情况的状态是在这里控制和使用，即使存储的技术细节它被委托给基础设施。这一层是核心商业软件。

[我的重点]

一般来说，他的博客文章很好地介绍了 DDD 中的一些概念。

【讨论】：