Question

我与合作伙伴讨论过这个场景：

**Publishers root entity 
Advertiser root entity**

每个实体都有共同的信息： 电子邮件，BillingAddress，NormalAddress，性别，SSN等

我决定：具有Value对象的Person实体地址和其余属性。这样，如果我想访问有关Person（电子邮件，性别，dateofbird）的特定信息，我不必通过发布者或广告客户根实体来获取它（将Person视为聚合根）。

Sample: **Person.BillingAddress.Address1 :
        Person.BillingAddress.Address2 :
        Person.BillingAddress.POBOX :
        Person.Email :
        Person.Sex**

我的队友建议使用抽象类，广告客户和发布者继承自Person抽象类，以便拥有所有常见属性。

最好的方法是什么？如果您有，请指导我们。

谢谢，佩德罗·德拉克鲁兹

Answer 1

我认为你是对的。当行为很常见时（某些东西是一种其他的东西），继承才有意义，那么人不仅仅是因为属性类似于其他东西。它不是代码重用。

Answer 2

你应该favour composition over inheritance。

您的设计更好，否则如果在某些时候您需要在此层次结构中引入其他内容（例如，使您的根实体AuditableEntity），您将无法这样做（除非您的语言支持多重继承 - 这是不好的）。

Answer 3

在这种情况下我不关心继承 - 我认为它很脆弱。

我更喜欢基于构图和角色的方法。管理员角色可以包装Person对象，并具有与角色关联的所有特殊属性和行为。

Answer 4

我认为广告客户和发布商应该继承公司，而公司应该有一系列联系人（或您的案例中的人员）。

从技术上讲，公司可以拥有一系列分支机构。

然后每个分支都有一个地址，每个联系人（人）都可以有一个地址。

Answer 5

@ Scott继承人的问题是什么？

@Tim如何继承失败？

将Person作为抽象类，将Advertiser和Publisher作为具体类。通过这种方式，广告商将拥有共同的属性，对于发布者而言，现在我们可以传递人。

广告商是人。出版商是人。我更喜欢继承

Answer 6

我的2美分......

当我正在阅读你的问题时，看来自然人并不是你模特的一部分。您的模型涉及发布商和广告商。

首先。我认为自然人（或公司）必须生活在一个独立的“层级参考”中。域，可以转换为＆＃34;层或合作伙伴存储库＆＃34;。

第二。由于您的模型需要发布商和广告商，我认为应该由DAL（以及存储库，但以较小的方式）负责定义和创建这些实体。 DAL是你应该拥有物理人物项目的唯一地方（因为它不是模型中的实体，我称之为＃34;项目＆＃34;），你应该注意将它与模型隔离开来。自然人必须留在数据方面，因为它在出版商和合作伙伴实体的构建计划中有所暗示。对这些实体进行精炼和保湿应该在存储库中。

我认为你不应该有一个＆＃34; Person＆＃34;在你的模特中，我认为你应该拥有它＆＃34; under＆＃34;存储库，从模型中看不到。

Answer 7

（警告 - 过于简单化）

在这种情况下的继承失败了“是一个”测试..

通常你会问“是”我的班级“a”<whatever>还是“有”<whatever>

Answer 8

我知道已经有很多年了，在这里回答我为时已晚。

这不是 DDD 域建模的问题。这是面向对象的领域建模。因此，这个问题本身很容易引起误解。

几年前，DDD一词几乎没有什么用，但在微服务时代，DDD的重要性突然上升。因此，对于所有微服务爱好者来说，这个问题会引起很多混乱。

DDD域模型一定不能与OO域模型混淆

DDD - 领域模型问题

8 个答案: