DDD：是否可以将服务注入实体

Question

我有一棵Zone对象树：

class Zone {
    protected $parent;

    public function __construct(Zone $parent) {
        $this->parent = $parent;
    }
}

Zone中没有 children或descendants属性，因为我想避免在域模型中管理这些关系的痛苦。

相反，域服务在数据库中维护一个闭包表，以将区域映射到任何级别的所有后代。

现在，我有一个User可以分配一个或多个区域的：

class User {
    protected $zones;

    public function assignZone(Zone $zone) {
        $this->zones[] = $zone;
    }
}

我的问题是，在为用户分配新区域之前，我想检查该区域是否尚未通过其后代之一显式或隐式分配。

因此，我希望我的控制器暂时将服务注入此方法，以执行必要的检查：

class User {
    protected $zones;

    public function assignZone(Zone $newZone, ZoneService $zoneService) {
        foreach ($this->zones as $zone) {
            if ($service->zoneHasDescendant($zone, $newZone)) {
                throw new Exception('The user is already assigned this zone');
            }
        }

        $this->zones[] = $zone;
    }
}

这是一个好的做法，或者如果不是，正确的选择是什么？

Answer 1

区域中没有子属性或后代属性，因为我想避免在域 模型中管理这些关系的痛苦。

相反，域服务在数据库中维护一个闭包表，以将区域映射到其任何级别的所有后代。

我加了一些强调，因为这看起来有点矛盾。您不希望域中出现“痛苦”，但您可以在域服务中管理闭包表。您需要将服务注入实体的事实有时表明设计可以改进。

看起来您有一个区域层次结构。这似乎是您域的重要组成部分。区域有父区域和子区域，因此也许您应该相应地对其进行建模。管理关系的痛苦是一种“合理”的痛苦，因为你这样做是为了模型表现力。在这种情况下，域驱动设计。所以区域本身会有类似的东西：

zone->hasDescendant($newZone)

而且您不需要注入服务。事实上，您根本不需要服务。因为这项服务的唯一原因是维护闭包表。这不是领域问题，只是持久性问题。

如果由于某些原因您仍然需要服务，最好将其注入到 Zone 类中。这样，问题就可以更接近其根源得到解决。