DDD:子类和根实体 [英] DDD: subclasses & root entities

问题描述

假设我有一个典型的实体 Car

Let's say I have the typical entity Car

class Car : Entity
{
    public double MaxSpeed { get; set; }
    public Color Color { get; set; }
    /* ... */
}

在我的域模型中，该实体将是汇总的根实体.

This entity, in my domain model, would be the root entity of an Aggregate.

现在让我说我专门研究汽车.我创建了 Ferrari ，法拉利(Ferraris)的快乐主人喜欢用昵称来称呼他们

Now let's say I specialize cars. I create a Ferrari, and the happy owners of Ferraris like to call them by a nickname:

class Ferrari : Car
{
    public string Nickname { get; set; }
}

假设我还有另一个实体， 公司 实体.这将是另一个 Aggregate 的根实体.有很多人在公司工作，由实体 Person 代表.人可能有车.但是公司的 总裁 通常非常富有，这种人有法拉利车:

Let's say I have another entity, the Company entity. It would be the root entity of another Aggregate. There are many people working on a company, represented by the entity Person. Persons may have cars. But the President of a company is usually very rich and this kind of people, they have Ferraris:

class President : Person
{
    public Ferrari Ferrari { get; set; }
}

在这种情况下，我有一个实体总裁，即公司汇总内部的，该实体总裁引用的是法拉利(法拉利的基础实体)另一种聚合.

In this situation, I have the entity President, who is inside the Company Aggregate, that is holding a reference to a Ferrari, an specialization of the root entity of another aggregate.

鉴于DDD，这是否正确?我可以/应该考虑将根实体本身专门化为同一聚合的根实体吗?我的意思是，在我所描述的领域中，法拉利实体是否也是汽车集合体的根实体(因为法拉利也是汽车)?

Is this correct in view of DDD? Can/should I consider the specialization of root entities themselves as root entities of the same aggregate? I mean, in the domain I described, is the entity Ferrari also the root entity of the Car Aggregate (since Ferrari is also a Car)?

现在让我们说我必须将此模型持久化到数据库.我认为我的问题不取决于我将使用的OR/M框架.

Now let's say I have to persist this model to a Database. I think that my question does not depend on the OR/M framework I will use.

我应该如何建造可容纳汽车的桌子?我是否应该使用"CarType"列(可能的值:"Car"，"Ferrari")和可空的昵称"列来构建单个表Cars?

How should I build the table holding Cars? Should I build a single table Cars, with a "CarType" column (possible values: "Car", "Ferrari"), and a nullable Nickname column?

还是我应该为Cars建立一个表，为Ferrari建立一个表，后者的PK为Car FK?

Or should I build a table for Cars and a table for Ferraris, the latter one having its PK a FK of Cars?

谢谢！

推荐答案

我认为您通过创建这些实体的具体类型开始失去很多系统的灵活性.我所暗示的关系类型通常是我与类型"实体所处理的.例如，您有车.法拉利是汽车的一种.承载的两个实体是Car和CarType.

I think you start losing a lot of the flexibility of the system by creating concrete types of these entities. The type of relationship that you are implying is something I generally hand with a "Type" entity. For example, you have a car. A Ferrari is a type of car. The two entities that are borne from that are a Car and a CarType.

您谈论这样做的方式，每次引入新类型时都必须添加新实体.如果您要捕获的只是汽车的昵称"，我认为那只是另一部分数据，而不是另一实体.除非您在不同类型的Car实体中具有不同的数据(即，不同的属性名称)和/或行为差异，否则使用此方法不会有太多好处.我宁愿使用诸如FindCarByType()之类的存储库方法并处理一种类型的实体，以降低风险.

The way that you are talking about doing it, you would have to add new entities every time a new type is introduced. If all that you are trying to capture is the "nickname" of the car, I would think that is just another piece of data, and not another entity. Unless you have different data (i.e. different property names) and/or behavior differences in Car entities for different types, you do not gain much with this approach. I would rather have repository methods like FindCarByType() and deal with one type of entity, to reduce risk.

我绝不是DDD专家，我正在为某些概念而苦苦挣扎(或更像是在为某些概念的多种解释而苦苦挣扎).我发现没有100％的纯实现，而且我看到的每个实现都有细微差别.

I am by no means a DDD expert, and I am struggling with some concepts (or more like struggling with the multiple interpretations of some concepts). I am finding that there is not a 100% pure implementation, and that there are nuances to each implementation that I have seen.

编辑关注

我发现我误读了您写的部分内容.我知道这个昵称并不适用于所有车辆，而仅适用于法拉利:汽车.我认为答案确实是取决于".您在模型的其余部分中拥有多少个领域专业化知识?在法拉利实体中，昵称可能很普遍，但这是专有的吗?它不仅与实际数据有关，而且与要求有关.基本上，这取决于您对这些实体所期望的专业化程度.

I see that I misread part of what you had written. I see that nickname is not for all vehicles, but just for Ferrari : Car. I think that the answer is really "it depends". How much domain specialization do you have in the rest of your model? Having a nickname might be prevalent amongst Ferrari entities, but is it exclusive? It isn't only about the actual data, but the requirements. Basically it comes down to how much specialization your are expecting in these entities.

这篇关于DDD:子类和根实体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！