针对新手的域驱动设计实体建议

Question

我正在尝试学习域驱动设计。目前，我正在为一个虚拟的个人项目整理一个上下文地图，该项目旨在存储有关客户和潜在客户的信息（还有电子邮件模板引擎和其他一些信息）。

我偶然碰到一个小障碍；我的问题是我创建了一个用于存储有关客户和公司信息的有限上下文。有两种类型的客户端，即转包的代理客户端和最终客户端。

我不确定是否应该将其建模为具有客户端类型值类型的客户端，还是作为客户端和代理客户端的单独域实体？任何建议将不胜感激。

---

请注意

上图不完整，因此缺少一些链接。如果我在这里做错了明显的事情，请不要犹豫，让我知道。

我还使用箭头代替上游/下游箭头，因为我认为它们在视觉上会更好一些。

---

Answer 1

对此进行建模的方式将取决于您的应用程序和业务领域的要求。

在我看来，ProxyClients缺少某些东西。如果他们转包合同，那么他们应该参与某种Project的{​​{1}}吗？

我只是假设是这种情况，然后将EndClient添加到模型中。

现在，客户可以一次为一个Project来EndClient，又一次为另一个Project吗？

如果答案为是，那么您将需要一个单独的SubClient，可以为ClientEntity分配一个ClientType或Role。 Project本身是没有意义的，仅对于Role存在。

在模型中使用Project或ClientType作为单独概念的优点是它是动态的，您可以更改ClientRole的类型或分配多种类型/角色。 / p>

使用不同的实体将阻止您执行此操作。如果在应用程序生命周期的后期，需求发生变化，则必须重构为其他设计。离开旧的设计并将Client转换为SubClient可能是不可能的，否则您将需要存储此EndClient完成的所有项目的所有信息。解决此问题的另一种方法是让一个客户在EndClient和ProxyClients中都拥有副本

另一方面，如果您不需要单独使用EndClients进行设计的灵活性，那么使用不同的实体会更好。这样做的好处是可以清楚地区分要处理的客户端类型，并使系统更简单。

有关此主题的更多信息，请检查this article

现在进入模型和设计。

当某人回答您的问题时，一个人可以做两件事。一种是回答您所问的直接问题。

另一种方法是注意到设计，模型等方面的问题，并为此提供反馈。

您说有些东西丢失了，但是很重要。我确实回答了您的具体问题，但是少量的信息使我无法向您提供有关您的设计的更多反馈，并为您提供一些可能出现错误的指导。

Type/Role是我不理解的一件事。 ProxyClient是Company的{​​{1}}，这就是为什么此客户端为此SubContract的{​​{1}}或被聘请Client来做ProxyClient代表Company，它雇用了您称为Company的{​​{1}}。

这一点对您的设计很重要，但尚不清楚。因为如果您是第二种情况，那么我会说您的概念可能需要更改。例如，您有Project在做这项工作，而不会将其称为EndClient，因为这没有意义。这将以新概念改变整个模型。

下一次尝试提供更多信息或尝试得出更简单，更清晰的案例。有时原始案例很复杂，因此您可能需要提出一个类似但更简单的案例来面对相同的问题，以免让人感到困惑。还提供有关您的应用程序和域的更多信息。事物应该如何工作以及它们之间的关系是什么。