domain-driven-design - DDD 客户、联系人和地址(聚合根)

Question

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

我的聚合根是一个 Customer 类，它包含一个 Addresses(地址簿)集合、一个 Contacts 集合和一个通信历史集合。

看起来这个聚合根会很大，具有修改地址、联系人(可以有 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 的值对象......我不知道如何在没有它的情况下将更改持久保存到我的 Customer 表中。

任何人，如果我的结构变得如此庞大，我就会觉得我走上了错误的道路。有人做类似的事情吗？不确定如何分解结构并维护基本业务规则(例如确保在将地址设置为默认帐单或运输之前将地址分配给客户)。

Answer 1

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

客服

计费

航运

等

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

客服:联系方式、联系历史

帐单:帐单地址、付款信息、订单

送货:订单项，送货地址

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

Steve Smith 和 Julie Lerman 有一门关于 Pluralsight 的精彩类(class)，名为 Domain-Driven Design Fundamentals，其中深入介绍了这些概念。