Oop DDD：建模两个根之间的M:N关系，其中关系本身具有语义

更新编辑以反映Chris Holmes要求的澄清。最初，我将终端称为站点，但为了更好地反映我的实际领域，我对其进行了更改

本质上，我认为这是一个关于在两个根实体之间建模多对多关系的问题，其中关系本身具有一些语义含义

在我的领域

• 你可以把航站楼看作是我们公司的一个分支机构
• 终端可以与任意数量的客户建立关系
• 客户可以与任意数量的终端建立关系（标准多对多）
• 客户\终端关系意味着客户可以在终端存储产品
• 此关系可以启用\禁用。禁用仅仅意味着暂时不允许您存储产品，所以禁用的关系不同于完全没有关系
• 一个客户可以有许多办公室
• 与客户（已启用或未启用）有关系的终端必须具有与之通信的该客户的默认办公室
• 有一些默认设置应用于客户和终端之间的所有交易，这些设置是在终端客户关系级别上设置的

我认为我这里的对象非常清楚，终端，客户，办公室，以及终端客户关系（因为有专门存储的关于关系的信息，例如是否启用、默认办公室、ad默认设置）。通过多次重构，我确定终端和客户都应该是聚合根。这就给我留下了一个问题：如何设计TerminalCustomerRelationship对象来将两者联系起来

我想我可以使从终端到终端客户关系的遍历单向地指向关系，但我不知道如何断开与客户的关系，特别是因为它需要包含对与客户有关系的办公室的引用

我是新手，虽然DDD的大部分内容都很有道理，但我感到困惑，需要一个全新的视角。有人能告诉我他们对如何处理这种情况的看法吗

---

请注意，我说的是关系而不是关系。在我目前的观点中，它应该成为一个对象，就像婚姻应该成为一个婚礼礼拜堂申请中的对象一样。它最明显的用途是将两个对象关联起来，但它也有其他理应属于它的属性。

您不应该拥有SiteCustomerRelationship这样的对象，它是特定于数据库的

如果是真正的DDD，您应该有如下关系：

Aggregate<Site> Customer.Site
IEnumerable<Aggregate<Office>> Customer.Offices

Aggregate Customer.Site
IEnumerable客户办公室

也许

Aggregate<Office> Customer.DefaultOffice

Aggregate Customer.DefaultOffice

名称通常可以明确对象的职责，并使域模型成为焦点

我不清楚什么是网站，这让整个模型变得混乱，这让我很难提供更好的建议。例如，如果一个站点是一个供应商，那么很容易将SiteCustomerRelationship重命名为合同。在这种情况下，将合同作为自己的实体，并使模型看起来像供应商合同客户办公室，这是非常有意义的

---

还有其他的方法来看待这个问题。Udi在这种多对多的关系上有一个不错的帖子

根据您的描述，您肯定需要一个“终端客户关系”实体来跟踪相关信息。我还将把“IsEnabled”标志转换成一个带有时间戳的第一类“事件”实体-这使您能够保存状态更改的历史记录（更真实地查看域中发生的情况）

这里有一个（在VS2008中）反映了您的问题。您可以调整/测试代码，直到关系有意义为止。运行“bin/debug/TerminalSampleApp.exe”并右键单击“终端->创建示例”开始

---

如果您觉得有用，请告诉我。

这是一种关系，而不是关系（这是数据库特有的）。关系本身具有属性（例如是否处于活动状态、默认设置和默认办公室）。丈夫和妻子之间的关系/婚姻也可能成为一个对象（婚姻的长度、孩子的数量等）。我的观点是，是积极的/消极的关系，还是客户。如果客户的属性不是在它们之间有一个“元数据”实体，而是处于非活动状态的关系，那么这将是一个更简单的模型。这就是我所说的婚姻的例子。如果建立一个夫妻领地，那么婚姻作为一个对象是合理的。我的SiteCustomerRelationship是一个完全相同意义上的对象。以后可能会有一个不同的名称。在我的实际模型中，它被称为终端（领域专家称之为终端），我将其重命名为Site，因为我认为它不会那么混乱。失败。您可以将其视为我们公司的一个分支机构。将其重命名为合同是可以的，但合同已经是系统中的实体，因为它们对我们的用户具有稍微不同的含义。老实说，这是我能想到的最好的名字。啊！这正是Udi在我需要的第二到最后一部分中所掩盖的部分。我应该重构到有界上下文吗？我还没有读过这本书的那部分！那么客户关系是一个帐户吗？他们在你的网站上做了什么，使得在模型中捕获关系成为必要？他们在我们的终端上存储产品。这可能意味着合同的存在（用户对这个词的理解）。可以启用/禁用关系，这意味着客户无法存储产品