DDD - 从实体访问存储库，之二

Question

我上个月问过previous question，关于实体是否应该访问存储库，虽然看起来大多数人认为他们不应该，但我不得不承认我很难被说服。

我有一个用例，我真的想不出任何（合理）方法来执行逻辑而不在我的实体中注入存储库：

我们有一个Store，它被分配了一个Zone（城市、地区、... - 用户定义）。 为了减少负责将 Store 添加到数据库的员工的工作量，并确保一致性，我们不要求他选择要添加 Store 的 Zone。他只是放大地图，点击确定商店位置，然后保存。然后，应用程序必须找到与该位置最相关的区域。

我目前拥有的是这样的：

class Store
{
    protected Zone zone;
    protected Point location;
    protected ZoneRepository zoneRepository;

    public void setLocation(Point location)
    {
        Zone matchingZone = this.zoneRepository.findByLocation(location);
        if (matchingZone == null) {
            throw new ApplicationException(
                "The store location must be within a zone boundary");
        }
        this.location = location;
        this.zone = matchingZone;
    }
}

您是否有任何 可靠 替代方案来支持普遍接受的观点，即这种设计本质上是不好的？

Answer 1

不一定说这种设计不好。它只是提出问题。大多数时候不需要在实体中使用存储库。让 Store 根据地理点查找自己的区域似乎有点奇怪。看起来这个责任不属于商店。

是否总是需要积分？如果用户想从“最后 5 个区域”列表中选择区域怎么办？还是从国家/城市下拉菜单？还是从搜索文本框中？在这些情况下没有必要指出。要求点和存储库看起来像是根据 UI 模型定制域模型。

如果您确实需要为每个商店都设置一个积分，那么您可能不需要同时使用区域字段。如果您仅在需要时动态查找 Store 的 Zone 会怎样？使用最新的点对区数据库。

此外，如果您的 Store 类有 5 或 6 个方法，并且其中只有一个需要 zoneRepository 字段，那么该类就不是很cohesive。

Answer 2

从您提供的描述看来，Point 实际上并不是您的通用语言的一部分——Zone 是。您没有为商店设置点 - 您为其分配了一个区域。换句话说，这个操作的签名不应该是setLocation(Point location) - 它应该是assignZone(Zone locationZone)。用户选择的点和区域之间的转换应该在执行域模型操作之前发生。我就是这样建模的。

在 cmets 之后添加的示例（如果您不介意的话，可以使用 C# - 并且只显示一个概念）。代码采用基于命令的方法来执行用户操作 - 我倾向于这样做，但也可能是 Application Service 或 Controller，具体取决于应用程序的结构。

    public class StoreLocationHandler : Handles<LocateStoreCommand>
    {
        public void Handle(LocationStoreCommand command)
        {
            // Location contains coordinates as well as zone info and can be obtained only via LocationService
            Location location = LocationService.IdentifyZone(command.Coordinates); 

            Store store = StoreRepository.Get(command.StoreId);

            store.AssignLocation(location);

            // persist changes - either by Unit of Work or Repository
        }
    }

关键是您不必在域实体中创建所有内容 - 从 Store 的角度来看，区域似乎是值对象。此外，这两个概念的进一步分离可能会带来额外的可能性，例如通过某种后台进程而不是在线识别区域（为了性能或可伸缩性）。此外，在我看来，考虑到Dependency Injection 原则，它更适合。

毕竟，域并不关心区域是如何创建或检索的，它关心的是 Store 之间的关联、它的位置和它所在的区域。为什么它要负责一个点和一个区域之间的转换？至少我是这么看的。

Answer 3

就用于逐点搜索位置的 DDD 而言，您应该为它提供单独的服务，例如 LocationService，它将您的存储库封装在其中。并且该服务应该对User 存储实体一无所知，尤其是永远不要将存储库包含到实体中。

Answer 4

我使用相同的方法，并且和你一样，无法相信这是一个糟糕的设计。但是，我的存储库有接口，所以我不使用 ZoneRepository 的具体实现，因为这样它可能会变得很困难，并且取决于无法测试和模拟它的上下文。

另一点，正如@Samich 所说，从 Store 对象中获取基于点查找区域的知识听起来不错，因为稍后您可能想在其他地方使用此方法。如果您为区域实施服务，那么您将集中您的代码并避免冗余。