Question

我们正在使用DDD开展一个项目，但是他们仍然不知道如何对待查找实体。例如，我们有一个名为“Customer”的聚合，而实体“Customer”也是聚合根。实体“Customer”具有“CustomerTypeID”属性。

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

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

我对这个漫长的故事道歉，但这是我的问题：

我是否认为“CustomerType”是一个实体而不是一个价值对象？
“CustomerType”应该在聚合“客户”中，还是应该在其自己的聚合内部，因为我们将访问它并将其维护在特定客户的上下文之外？
如果这个实体和任何其他基本查找实体（如客户状态，产品类型等）的实体应该是自己聚合（并且是这些聚合的聚合根），我不会去最终有数百个存储库？（因为每个聚合根将拥有自己的存储库）

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

=================================== 我试着写一些代码来回复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点，聚合和有界上下文之间有什么区别？ “客户”聚合（“客户”是否为聚合根），它还包含仅存在于客户上下文中的任何实体和价值对象，而不是有界上下文？

Answer 1

是的，由于CustomerType具有身份和相关描述，因此它是一个实体。
Customer类是否具有CustomerType属性或CustomerTypeId属性取决于它是否需要访问CustomerType上的其他属性。无论哪种方式，CustomerType都是自己的实体，拥有自己的存储库。
如果您有数百个实体，特别是您指定的类型，那么它可能表明项目变得太大，您可能需要划分到适当的有界上下文中。

DDD - 如何处理查找实体？

1 个答案: