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

Question

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

假设我们有一个实体 Vehicle引用聚合根，Person , 通过身份 - a 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 ?这意味着我们需要转换 - 不理想。

Answer 1

据我了解，AggregateRoot 的松散定义不是子实体，子实体是只能引用另一个父实体才能理解的东西。例如，OrderLine 仅对 Order 有意义。
一个人和一辆车不是这个 - 在你的例子中，你可以有一个没有汽车的人，还有一个没有人的汽车。
对于这种情况，您有一个服务来管理聚合根之间的关系。
https://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/

The operation relates to a domain concept that is not a natural part of an Entity or Value Object

The interface is defined in terms of other elements in the domain model

The operation is stateless

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