处理贫血领域模型

Question

我试图将我的DAL与我的业务层分开，在这样做的时候，我决定避开任何ActiveRecord方法并采用DataMapper方法。 换句话说，我的域对象不会保持自己的持久性。在这样做的过程中，我似乎正在蚕食“贫血领域模型”。反模式。例如，我的程序中的一个实体是组织。

组织代表如下：

class Organization {
    private $orgId;
    private $orgName;

    // getters and setters
}

所以基本上这个组织除了扮演“包”之外什么都不做。 （正如Martin Fowler所说）的一些数据。在PHP世界中，它只不过是一个美化的数组。与之相关的行为为零。

在程序中的行为，我一直坚持“服务水平”。类似于OrganizationService的类，它主要充当这些对象和DAL之间的中介。

除了PHP的潜在扩展问题（我还有其他原因，我坚持在这些对象中“装袋”我的数据），这种方法完全不合适吗？

在这些情况下，您如何处理域模型？ 也许组织首先不属于我的域名？

Answer 1

好吧，它似乎在开头就是这样，但是当你更多地重构你的代码时，你会为你的组织类做出一些行为......

我现在想到的一个例子是，如果你有人（员工），你可能想要将他们与组织联系起来。所以，您可能有一个方法 AssociateEmployee（用户员工），可能会在您的组织类中找到它的位置。

或者您可以更改公司的位置，而不是分三步设置地址，城市，州等参数，您可以添加 ChangeLocation（Street，City，State）方法..

只需逐步进行，当您在BL /服务层中遇到一些似乎应属于域的代码时，将其移至域中。如果您阅读Fowler，当您在代码中看到它时，您很快就会知道它。

Answer 2

现在可能只是贫血？

例如，有一次我正在开发会议/会议注册网站。它始于一次会议。

还有一个会议班，只有一个例子，但是第二年我们举行了会议，它被扩大了，并且增加了新的房产（举行两次背靠背会议），显然它还没有完全我们随后增加了可以包含多个会议的会议组。

所以我认为重要的是要记住，域名会随着时间的推移而改变，而你的模型最终可能会被重构，所以即使你认为它很贫乏，也可能只是有点过于前瞻性（就像你的组织类一样）将开始获得一些设置，规则或偏好等。）

Answer 3

您可能还会考虑，如果您没有很多业务规则，或者域名并不复杂，那么DDD对您来说可能是一个过多的开销。 DDD对于大型复杂域来说是一个很好的解决方案，但如果您只是在数据输出中进行数据输出，则会产生很多开销和复杂性。 DDD更难设计并且固有地增加了复杂性，因此为了证明它，问题域的复杂性应该超过它。

这就是我要添加到zappan和epitka的所有内容。

Answer 4

您的实体并非贫血，因为您正在采取不应该在那里开始的可转让性。持久化和获取实体是存储库的可靠性。实际上，您的行为应该在您的实体中，而不是在服务层中。但解释什么在哪里超越简单的答案。 Eric Evans的DDD是一个很好的起点。