领域驱动设计是否需要在领域对象之外实现业务逻辑。

Question

域的模型是我用作POCOs 的实体，这意味着没有基类，周围没有接口，也没有属性。

所以像验证规则这样的业务逻辑必须在实体之外。 (Anemic Domain Model)

这是否符合领域驱动设计？

Answer 1

没有。不是真的。

领域驱动设计的主要目的是尽可能在模型中明确地捕获和封装业务领域。业务总是包含行为，因此 - 你的对象也应该有行为。

域的模型是我用作 POCO 的实体，这意味着没有基类，没有接口，也没有属性。

...没有c#，应该使用.net clr。那是基础设施，对吧？ ;)

这些是表达你的模型的工具。你应该尽量降低噪音水平，分离你的模型，但你不能完全失控，因为它是用编程语言和围绕它的技术表达的现实生活模型。

顺便说一句，您可能想研究永远不允许域对象处于无效状态的想法。如果它觉得这种特定类型的验证与业务无关 - 它首先不应该在域模型中。

Answer 2

这是一个非常哲学的问题。我真的很想给出一个同样富有哲理的答案，所以这里是：

正如我所理解的领域驱动设计，最重要的是，谁知道某事，谁就用这些知识做事。我相信这与this article 交织在一起。

考虑到这一点，您的普通旧对象应该具有执行其“生死攸关”的方法 - 重要任务（这会使您的解决方案出错）。

然而，另一种看待它的方式是，这些普通的旧对象是最小的可用数据集，几乎就像原语一样。然后发生的是拥有这些数据对象的对象，它们是域驱动设计中的实际模型对象。并且它们不必完全相关（这将使您的解决方案正确）。

如果模型和数据层是由两个完全独立的设计师设计的，或者如果一个人能够转换帽子，这很容易发生。或者也许是一点点.... wohoooooo D：我认为这可能是件好事！我举个例子：

论坛

我们需要什么？我们需要用户、板、线程和帖子。最后 3 个在数据层都有 “一对多” 的关系。一个板有很多线程，一个线程有很多帖子。一个用户也有很多帖子，并且一个用户启动了很多线程（可以通过在线程中找到第一个帖子的作者得出，因此可能不必存储在数据层中）。但是表示层发生了什么？

查看板时，我们希望查看该板中所有可用的线程。但我们不会满足于看到线程的名称和启动它的用户的名称。我们还想查看每个线程中的帖子数量，以及线程中最后一位发帖人的姓名，以及该帖子的发布时间。

我们现在正在查看一个与数据层有些不同步的模型对象。它将包含从给定数据对象计算所需数据的业务逻辑，然后它将能够使用视图所需的数据加载某种视图。模型中不需要 getter 或 setter，因此封装永远不会被破坏。模型对象符合领域，应该取决于可用性需求，而不是数据存储的限制。数据对象符合旧的数据存储方式。

这将为我们提供数据抽象层（使用 pocos）、mvc、和领域驱动设计。赢？ :)