DDD 客户、联系人和地址（聚合根）

Question

我正在构建一个应用程序来管理我公司的大部分 LOB 内容。我正试图围绕 DDD... 从客户管理开始。关于域模型，许多示例非常非常简单，对我没有多大帮助。

我的聚合根是一个 Customer 类，其中包含地址集合（通讯录）、联系人集合和通信历史集合。

似乎这个聚合根会很大，具有修改地址、联系人（可以有 x 个电话号码）和通信的功能。

例如

UpdateCustomerName(...)
SetCustomerType(...) // Business or individual
SetProspect(...) // if the customer is a prospect
SetDefaultPaymentTerms(...) // line of credit, etc. for future orders
SetPreferredShippingMethod(...) // for future orders
SetTaxInfo(...) // tax exempt, etc.
SetCreditLimit(...)
AddAddress(...)
RemoveAddress(...)
UpdateAddress(...)
VerifyAddress(...)
SetDefaultBillingAddress(...)
SetDefaultShippingAddress(...)
AddContact(...)
UpdateContact(...)
RemoveContact(...)
SetPrimaryContact(...)
AddContactPhoneNumber(...)
RemoveContactPhoneNumber(...)
UpdateContactPhoneNumber(...)
AddCommunication(...)
RemoveCommunication(...)
UpdateCommunication(...)
etc.

我读到值对象没有身份。在这个系统中，每个地址（在数据库中）都有一个 ID，并且有一个 customerId 作为外键。如果地址是它自己的聚合根，那么我将无法使用我的业务逻辑来设置默认计费/运输。许多示例都有没有 ID 的值对象...我不知道如何在没有 ID 的情况下将更改保存到我的 Customer 表。

任何人，如果我的结构变得如此巨大，我感觉我的结构走错了路。有人做类似的事情吗？不知道如何分解结构并维护基本业务规则（例如在将地址设置为默认计费或送货之前确保将地址分配给客户）。

Answer 1

您之所以反对业务逻辑应该位于何处的问题，是因为您混合了有界上下文。 LoB 应用程序是 DDD 中的典型示例之一，其中大多数显示应用程序被分解为多个有界上下文：

• 客户服务
• 计费
• 运费
• 等

每个有界上下文可能需要来自您的 Customer 类的一些信息，但很可能不是全部。在处理实体的定义时，DDD 违背了标准的 DRY 概念。定义多个 Customer 类是可以的，一个用于需要它的每个有界上下文。在每个限界上下文中，您将定义具有属性和业务逻辑的类，以满足该限界上下文中的要求：

• 客户服务：联系信息、联系记录
• 账单：账单地址、付款信息、订单
• 送货：订单项、送货地址

这些有界上下文都可以指向同一个数据库或多个数据库，具体取决于系统的复杂性。如果它是同一个数据库，您将设置数据访问层以填充有界上下文所需的属性。

Steve Smith 和 Julie Lerman 开设了一门很棒的 Pluralsight 课程，名为 Domain-Driven Design Fundamentals，深入介绍了这些概念。