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

Question

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

但我们也有一个实体“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
    ...

和

公共(public)类 CustomerType
继承 EntityBase(Of Integer)
实现 IAggregateRoot

    Public Property CustomerTypeID As Integer
    Public Property CustomerTypeDescription As String

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

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

Answer 1

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

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

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