领域驱动设计和 IoC/依赖注入

我现在正在尝试应用我学到的有关 DDD 的知识，但我对域模型中的依赖关系流有点困惑。

我的问题是：

1. 实体是否应该了解域中的工厂、存储库、服务？
2. 存储库应该了解域中的服务吗？

另一件困扰我的事情是当我想向集合添加实体时如何处理集合。

假设我正在开发一个简单的 CMS。在 CMS 中，我有一个文章实体和标签集合，其中包含标签实体。

现在，如果我想添加带有新标签的关系。更好的方法是什么？ （PHP 中的示例）

$article->tags->add(TagEntity);
$articleRepository->save($article);

或者我可以通过服务来做到这一点。

$articleService->addTag($article, TagEntity);

你怎么认为？

Thanks.

实体和值对象永远不应该相互依赖。这些是所有内容中最基本的DDD 的构建块 http://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks_of_DDD。它们代表了您的问题域的概念，因此应该关注问题。通过使它们依赖于工厂、存储库和服务，您会使焦点变得模糊。在实体和值对象中引用服务还存在另一个问题。因为服务也拥有域逻辑，所以您可能会想将域模型的一些职责委托给服务，这最终可能会导致贫血域模型 http://en.wikipedia.org/wiki/Anemic_domain_model.

工厂和存储库只是用于创建和持久化实体的助手。大多数时候，它们在实际问题领域中没有类比，因此根据领域逻辑，从工厂和存储库到服务和实体的引用是没有意义的。

关于您提供的示例，这就是我的实现方式

$article->addTag($tag);
$articleRepository->save($article);

我不会直接访问底层集合，因为我可能想要Article在上执行一些域逻辑（施加约束，验证）Tag在将其添加到集合之前。

避免这种情况

$articleService->addTag($article, $tag);

仅使用服务来执行概念上不属于任何实体的操作。首先，尝试将其适合实体，确保它不适合任何实体。然后才使用服务。这样你就不会得到贫乏的领域模型。

UPDATE 1

引用 Eric Evans 的《领域驱动设计：解决软件核心的复杂性》一书：

应谨慎使用服务，不得剥夺服务的权利 他们所有行为的实体和价值对象。

UPDATE 2

有人否决了这个答案，我不知道为什么。我只能怀疑其中的原因。它可能与实体和服务之间的引用有关，也可能与示例代码有关。好吧，我对示例代码无能为力，因为这是我根据自己的经验得出的意见。但是，我对参考文献部分做了更多研究，这就是我得出的结论。

我并不是唯一一个认为从实体引用服务、存储库和工厂不是一个好主意的人。我在 SO 中发现了类似的问题：

• 实体可以访问存储库吗？ https://stackoverflow.com/questions/827670/is-it-ok-for-entities-to-access-repositories
• DDD - 领域模型、服务和存储库之间的依赖关系 https://stackoverflow.com/questions/756849/ddd-dependecies-between-domain-model-services-and-repositories
• DDD - 实体不能直接访问存储库的规则 https://stackoverflow.com/questions/5694241/ddd-the-rule-that-entities-cant-access-repositories-directly
• 使用服务的 DDD 实体 https://stackoverflow.com/questions/2380882/ddd-entities-making-use-of-services

还有一些关于该主题的好文章，尤其是这篇文章How not在实体中注入服务 http://thinkbeforecoding.com/post/2009/03/04/How-not-to-inject-services-in-entities如果您迫切需要从您的实体调用名为的服务，它还提供了一个解决方案双重派遣 http://en.wikipedia.org/wiki/Double_dispatch。以下是移植到 PHP 的文章中的示例：

interface MailService
{
    public function send($sender, $recipient, $subject, $body);
}

class Message
{
    //...
    public function sendThrough(MailService $mailService)
    {
        $subject = $this->isReply ? 'Re: ' . $this->title : $this->title;
        $mailService->send(
            $this->sender, 
            $this->recipient, 
            $subject, 
            $this->getMessageBody($this->content)
        );
    }
}

因此，正如您所看到的，您没有对MailService服务于您的Message实体，而是将其作为参数传递给实体的方法。本文作者提出了同样的解决方案“DDD：服务 http://devlicio.us/blogs/casey/archive/2009/02/17/ddd-services.aspx" at http://devlicio.us/ http://devlicio.us/在评论部分。

我还尝试了解 Eric Evans 在他的《领域驱动设计：解决软件核心的复杂性》一书中对此的说法。经过简短的搜索，我没有找到确切的答案，但我找到了一个示例，其中实体实际上静态地调用服务，即没有对其的引用。

public class BrokerageAccount {
    String accountNumber;
    String customerSocialSecurityNumber;

    // Omit constructors, etc.

    public Customer getCustomer() {
        String sqlQuery =
            "SELECT * FROM CUSTOMER WHERE" +
            "SS_NUMBER = '" + customerSocialSecurityNumber + "'";
        return QueryService.findSingleCustomerFor(sqlQuery);
    }

    public Set getInvestments() {
        String sqlQuery =
            "SELECT * FROM INVESTMENT WHERE" +
            "BROKERAGE_ACCOUNT = '" + accountNumber + "'";
        return QueryService.findInvestmentsFor(sqlQuery);
    }
}

下面的注释说明如下：

注意：QueryService，一个用于从数据库获取行的实用程序 和创建对象，解释示例很简单，但它是not对于实际项目来说必然是一个好的设计。

如果您查看我上面提到的 DDDSample 项目的源代码，您会发现实体除了对象中的对象外没有任何引用。model包，即实体和值对象。顺便说一句，DDDSample 项目在《领域驱动设计：解决软件核心的复杂性》一书中有详细描述...

另外，我想与您分享的另一件事是关于领域驱动设计雅虎集团 http://tech.groups.yahoo.com/group/domaindrivendesign/message/2300. This message http://tech.groups.yahoo.com/group/domaindrivendesign/message/2305讨论中引用了 Eric Evans 关于引用存储库的模型对象主题的内容。

结论

总而言之，从实体引用服务、存储库和工厂并不好。这是最被接受的意见。尽管存储库和工厂是域层的公民，但它们不是问题域的一部分。有时（例如在维基百科关于 DDD 的文章中）域服务的概念被称为纯制造 http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Pure_Fabrication这意味着类（服务）“不代表问题域中的概念”。我宁愿将工厂和存储库称为 Pure Fabrications，因为 Eric Evans 在他的书中确实谈到了有关服务概念的其他内容：

但当手术时实际上是一个重要的领域概念， A 服务构成模型驱动设计的自然组成部分。声明于 将模型作为服务，而不是作为不存在的虚假对象 实际上代表什么，独立操作不会误导 任何人。

根据上述内容，有时从您的实体调用服务可能是明智的选择。然后，您可以使用双重调度方法，这样您就不必在实体类中保留对服务的引用。

当然，总有一些人和作者一样不同意主流观点的人。从实体访问域服务 http://danhaywood.com/2010/04/30/accessing-domain-services-from-entities/文章。