DDD - 应该如何处理查找实体？

Question

我们正在开发一个使用 DDD 的项目，但在如何处理查找实体上遇到了困难。 例如，我们有一个名为“Customer”的聚合，实体“Customer”也是聚合根。实体“Customer”具有属性“CustomerTypeID”。

但我们还有一个实体“CustomerType”，代表所有现有的客户类型（ID 和描述）。将有一个管理功能，允许用户维护客户类型（即添加新的客户类型等）。

请注意，我不是在谈论更改特定客户的客户类型，而是在谈论维护客户类型列表。

对于冗长的故事，我深表歉意，但以下是我的问题：

• 我认为“CustomerType”是实体而不是值对象的想法对吗？

• “CustomerType”应该位于聚合“Customer”内部，还是应该位于其自己的聚合内部，因为我们将在特定客户的上下文之外访问它并维护它？

• 如果该实体和作为基本查找实体的任何其他实体（例如客户状态、产品类型等）应该自行聚合（并且是这些聚合的聚合根），我最终不会得到数百个存储库？ （因为每个聚合根都有自己的存储库）

正如您所看到的，我在这里陷入了困境，只需要指出正确的方向。

===================================== 我试图编写一些代码来回复 eulerfx 的回复，但我无法让它工作，所以我将它放在这里。

关于第 2 点，在屏幕上我们显然只会显示类型的描述（例如“个人”）。这是否意味着我最终会得到这样的结果？：

Public Class Customer
    Inherits EntityBase(Of Integer)
    Implements IAggregateRoot

    Public Property CustomerID As Integer
    ...
    Public Property CustomerType As CustomerType
    ...

和

公共类 CustomerType 继承EntityBase（整数） 实现 IAggregateRoot

    Public Property CustomerTypeID As Integer
    Public Property CustomerTypeDescription As String

或者“Customer”类中的属性应该是 CustomerTypeID 吗？

关于第 3 点，聚合上下文和有界上下文有什么区别？ “Customer”聚合（“Customer”是聚合根）还包含仅存在于 Customer 上下文中的任何实体和值对象，难道不是有界上下文吗？

Answer 1

1. 是的，由于 CustomerType 具有身份和关联的描述，因此它是一个实体。

2. Customer 类是否具有 CustomerType 属性或 CustomerTypeId 属性取决于它是否需要访问 CustomerType 上的其他属性。无论哪种方式，CustomerType 都是拥有自己存储库的实体。

3. 如果您有数百个实体，特别是您指定的类型，那么这可能表明项目变得太大，您可能需要划分为适当的有界上下文。