domain-driven-design - 限界上下文实现和设计

Question

假设我有两个有界上下文，即Shipping Context和Billing Context。这些上下文中的每一个都需要了解客户。

在数据级别，客户由CustomerTbl数据库中的表表示。此表包含描述客户的所有必要列。

中的列CustomerTbl（简化）：

• Name
• PhysicalAddress
• PaymentMethod

Shipping Context与Nameand相关PhysicalAddress，而Billing Context与Nameand相关PaymentMethod。

在运输上下文中，我对聚合进行了建模Recipient：

• RecipientName现在具有和的属性/值对象PhysicalAddress

在计费上下文中，我对聚合进行了建模Payer：

• PayerName具有和的属性/值对象PaymentMethod

Recipient和聚合都Payer被上下文边界完全分开。他们也有自己的存储库。

问题：

1. 使用同一个“数据库表”是否可以接受多个聚合（假设它们位于单独的有界上下文中）？

2. 在更多有界的上下文中可能需要客户数据。这不意味着每个有界上下文都有许多聚合、存储库和工厂实现吗？代码会有一定程度的冗余。这不会影响可维护性吗？

3. 跨聚合共享属性是否可以接受？一个例子是客户Name财产。这也意味着多余的验证码？

Answer 1

问答

1）使用同一个“数据库表”是否可以接受多个聚合（假设它们位于单独的有界上下文中）？

• 只要您遵循严格的策略来管理共享状态，我就可以接受。
• DDD 可以接受，因为域被认为比数据更重要。
• 只要在不引入（太多）隐藏成本的情况下完成工作，您的客户就可以接受。

2) 在更多有界的上下文中可能需要客户数据。这不意味着每个有界上下文都有许多聚合、存储库和工厂实现吗？代码会有一定程度的冗余。这不会影响可维护性吗？

不一定，看看共享内核模式。

3) 跨聚合共享属性是否可以接受？一个示例是客户名称属性。这也意味着多余的验证码？

与问题 1 的答案相同。关于冗余，一旦你有一个共享内核，你可以简单地将你的验证器类放在那里。

关于 DRY 和 DDD 之间的冲突：

优雅的代码不会不必要地使伟大的设计原则相互矛盾。通常有一种方法可以满足这些原则。你只是还没有找到它，因为要么你对原理不够了解，要么你没有足够地剖析你的问题。

（如果这听起来很教条，那是因为软件工程实际上是一种宗教）

Answer 2