3

我让我与合作伙伴讨论我们有这种情况：

**Publishers root entity 
Advertiser root entity**

这些实体中的每一个都共享公共信息： 电子邮件、BillingAddress、NormalAddress、性别、SSN 等。

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

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

我的队友建议使用抽象类来实现，广告商和发布者继承自 Person 抽象类，以便拥有所有通用属性。

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

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

4

8 回答 8

2

我认为你是对的。只有当行为很普遍时继承才有意义（某些事物是另一种事物），然后 Person 不是一种 OTHER THING 只是因为属性相似。它不是代码重用。

于 2011-01-12T20:46:04.070 回答
1

您应该更喜欢组合而不是继承。

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

于 2011-01-12T20:41:45.863 回答
1

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

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

于 2011-01-12T20:41:52.137 回答
1

我认为 Advertiser 和 Publisher 应该从 Company 继承，并且 Company 应该有一组联系人（或您的情况下的 Persons）。

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

那么每个Branch可以有一个Address，每个Contact（Person）也可以有一个Address。

于 2011-01-12T20:41:54.483 回答
1

@Scott 从 person 继承有什么问题？

@Tim 这里的继承如何失败？

设 Person 为抽象类， Advertiser 和 Publisher 为具体类。这样 Advertiser 将具有共同的属性，对于发布者也是如此，现在我们可以传递 person。

广告商是人。发布者是个人。我更喜欢继承

于 2011-01-12T20:47:36.570 回答
1

我的2美分...

当我阅读您的问题时，似乎物理人不是您模型的一部分。您的模型与发布商和广告商打交道。

第一的。我认为自然人（或公司）必须生活在一个单独的“Tier Reference”域中，该域可以转换为“Tier or Partner Repository”。

第二。由于您的模型需要发布商和广告商，我认为应该由 DAL（以及存储库，但以较小的方式）负责定义和创建这些实体。DAL 是您应该拥有物理人项目的唯一位置（因为它不是模型中的实体，我将其称为“项目”），并且您应该注意将其与模型隔离。物理人必须留在数据端，因为它在发布商和合作伙伴实体的建设计划中有所暗示。精炼和水合这些实体应该在存储库中。

我认为你的模型中不应该有一个“Person”类，我认为你应该把它放在存储库“下面”，在你的模型中是不可见的。

于 2015-08-25T14:02:24.507 回答
0

（警告 - 过于简单化）

在这种情况下，继承未通过“是”测试。

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

于 2011-01-12T20:45:09.140 回答
0

好吧，我知道已经有好几年了，我来这里回答太晚了。

  1. 这不是DDD领域建模的问题。这是面向对象的领域建模。所以这个问题本身是非常具有误导性的。

几年前提出 DDD 这个词几乎没有任何区别，但在微服务时代，DDD 的重要性突然上升。所以对于所有微服务爱好者来说，这个问题会造成很多混乱。

DDD 领域模型不得与 OO 领域模型混淆

于 2019-11-21T09:55:04.367 回答