领域驱动设计，实体懒加载

Question

我对领域驱动设计 (DDD) 还很陌生，但我的理解是您与应用程序服务对话，这是您的“模型”的入口。该服务可以与使用源（文件、数据库等）获取数据的存储库通信。存储库返回一个实体。

这就是我得到的全球理念。服务知道存储库但不知道实体等。

现在我有以下问题。

我有一个实体用户，如下所示（只是一个例子）

<?php    
class User
{
    protected $name;
    protected $city_id;

    public function getCity()
    {
         // return $city_entity;
    }
}

getCity() 函数返回城市实体。我希望此函数使用延迟加载，因此在使用用户存储库时注入 CityEntity 并不是真正的延迟加载。

我为这个问题提供了两种解决方案。但我觉得两者都违反了 DDD 原则。

我想出的第一个解决方案是在用户实体中注入城市存储库，这有缺点：如果您需要更多存储库，则必须将它们全部加载到实体中。它看起来像answer，但在我看来它只是存储库的包装器。那么为什么不直接注入存储库呢？

第二个解决方案，你给实体一个服务定位器。这样做的缺点是除非您阅读代码，否则您不再知道需要哪些存储库。

那么现在的问题是，在保持 DDD 主体不变的同时提供延迟加载灵活性的最佳方法是什么？

Answer 1

DDD 的要点之一是您的领域模型应该只表达有界上下文的普遍语言来处理业务规则。

因此，在 DDD 实体中，延迟加载是一种反模式。有一些原因：

1. 如果聚合仅包含确保业务不变性所需的数据，则它需要所有数据并且它们很少，因此eager loading 效果更好。
2. 如果您延迟加载数据，您的客户端必须处理比relevant in business terms 更多的异常路径
3. 您可以使用shared identifiers 来处理聚合之间的引用
4. 将专用查询用于投影目的很便宜（通常称为read-model）

恕我直言，您永远不应该将 DDD 实体用作数据访问技术：为此使用 DTO。

有关更多信息，您可以查看 Vaughn Vernon 的 Effective Aggregate Design。