4

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

但我们也有一个实体“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(Of Integer) 实现 IAggregateRoot

    Public Property CustomerTypeID As Integer
    Public Property CustomerTypeDescription As String

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

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

4

1 回答 1

5

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

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

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

于 2011-12-07T00:35:42.737 回答