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(Of Integer) 实现 IAggregateRoot

    Public Property CustomerTypeID As Integer
    Public Property CustomerTypeDescription As String

或者“客户”类中的属性应该是 CustomerTypeID？

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

Answer 1

1. 是的，因为CustomerType 有一个身份和相关的描述，所以它是一个实体。

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

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