domain-driven-design - 继承与聚合根

在领域驱动的设计中，我们鼓励构建丰富的实体，这些实体在领域中表达真实的概念。

假设我们有一个实体Vehicle，它通过标识引用一个聚合根Person-Vehicle由Person拥有。

但是，Vehicle可以在没有所有者的情况下存在，例如在制造之后。

您将如何建模？

一种方法可能是使用Nullable类型：

public class Vehicle : DomainEntity<Guid>
{
    public Guid? Owner { get; private set; }

    public Vehicle(...)
        : base(Guid.NewGuid())
    {
        //...
    }

    public Vehicle(Guid owner, ...)
        : base(Guid.NewGuid())
    {
        Owner = owner;
        //...
    }
}

另一种方法是使用多个类和继承：

public class Vehicle : DomainEntity<Guid>
{
    public Vehicle(...)
        : base(Guid.NewGuid())
    {
        //...
    }
}

public class OwnedVehicle : Vehicle
{
    public Guid Owner { get; private set; }

    public OwnedVehicle(Guid owner, ...)
        : base(Guid.NewGuid())
    {
        Owner = owner;
        //...
    }
}

我更喜欢使用第二种方法，但是是否可以这样真正地建模聚合根？

总根到底是什么？ Vehicle还是OwnedVehicle？

现在我们将有两个单独的存储库，还是该存储库返回基本类型Vehicle？这意味着我们将需要铸造-不理想。

最佳答案

据我了解，对AggregateRoot的宽松定义不是一个子实体，而一个子实体只能参考另一个父实体来理解。例如，OrderLine仅在Order方面才有意义。
人与车不是这样-在您的示例中，您可以有一个没有车的人，也可以有一个没有人的车。
对于这种情况，您可以使用一个服务来管理聚合根之间的关系。
https://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/

该操作涉及的领域概念不是实体或值对象的自然组成部分
接口是根据域模型中的其他元素定义的
该操作是无状态的

因此，在这种情况下，您可能有一个CarOwnersipService，可以更新Cars和People以实现所有权，但外界不知道谁的详细信息。这里的服务是有意义的，因为取决于应用程序，规则可能不同。例如，也许您可​​以在移动设备上查看谁拥有汽车，但仅在另一个应用程序中分配所有权？
让我在这里暂停的是该操作是无状态的-如果我们认为幂等服务是无状态的，则它确实满足定义，但否则不满足。

关于domain-driven-design - 继承与聚合根，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/30576656/