我正在尝试学习领域驱动设计。目前，我正在为一个虚拟的个人项目组合一个上下文映射，该项目旨在存储有关客户和潜在客户的信息（还有一个电子邮件模板引擎和其他一些位）。
我偶然发现了一个小障碍；我遇到的问题是我创建了一个有界上下文来存储有关客户和公司的信息。有两种类型的客户，分包代理客户和终端客户。
我不确定我是否应该将其建模为具有客户端类型值类型的客户端，还是作为客户端和代理客户端的单独域实体？任何建议将不胜感激。
请注意
上图不完整，因此缺少一些链接。如果我在这里做的事情明显错误，请不要犹豫，让我知道。
我也使用箭头代替上游/下游，因为我认为它们在视觉上更好一些。
【问题讨论】：
对此建模的方式将取决于您的应用程序和业务领域的要求。
在我看来，ProxyClients 缺少一些东西。如果他们分包合同，他们应该参与某种Project 以获得EndClient 可能吗？
我只是假设是这种情况并将Project 添加到模型中。
现在，一个客户是否可以一次成为EndClient，一次成为Project，另一次成为SubClient？
如果答案是肯定的，那么您将需要一个单独的ClientEntity，它可以为Project 分配一个ClientType 或Role。 Role 本身没有意义，它只为 Project 存在。
在模型中使用 ClientType 或 ClientRole 作为单独概念的一个优点是它是动态的，您可以更改 Client 的类型或分配多个类型/角色。
使用不同的实体会阻止您这样做。如果在应用程序生命周期的后期需求发生变化，您将不得不重构为其他设计。保留旧设计并将SubClient 转换为EndClient 可能是不可能的，否则您将需要存储此EndClient 完成的所有项目的所有信息。解决此问题的另一种方法是让一个客户在ProxyClients 和EndClients 中都有副本
另一方面，如果您不需要单独的Type/Role 设计的灵活性，您最好使用不同的实体。这样做的好处是可以清楚地区分您正在处理的客户端类型，并使系统更简单。
有关此主题的更多信息，请查看this article
现在进入模型和设计。
当有人回答您的问题时，一个人可以做两件事。一种是回答您提出的直接问题。
另一个是注意你的设计、模型等方面的问题并给你反馈。
你说缺少一些东西，但它们很重要。我确实回答了你的具体问题，但信息量太少，我无法就你的设计向你提供更多反馈，也无法就你可能出错的地方给出一些指示。
我不理解的一件事是ProxyClient。为Client 提供Company SubContract，这就是为什么此客户是ProxyClient 为Company 或者是Company 受雇为Project 为EndClient 做一个EndClient，它雇用了一个SubContractor 你称之为ProxyClient。
这一点对您的设计很重要，但尚不清楚。因为如果你是第二种情况，那么我会说你的概念可能需要改变。例如，您有一个 SubContractor 做这项工作，但不会称它为 ProxyClient，因为它没有意义。这将用新概念改变整个模型。
下次尝试提供更多信息或尝试推导出一个更简单、更清晰的案例。有时原始案例很复杂，因此您可能需要提供一个类似但更简单的案例，但也面临相同的问题，以免人们感到困惑。还要提供有关您的应用程序和域的更多信息。事情应该如何运作以及它们之间的关系是什么。
【讨论】：
ClientType 是最好的方法。