限界上下文实现和设计答案

【问题标题】：Bounded context implementation and design限界上下文实现和设计
【发布时间】：2014-03-03 00:02:42
【问题描述】：

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

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

CustomerTbl 中的列（简化）：

Shipping Context 与 Name 和 PhysicalAddress 相关，而 Billing Context 与 Name 和 PaymentMethod 相关。

在Shipping Context中，我已经为聚合建模Recipient：

在 Billing Context 我已经对聚合 Payer 建模：

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

问题：

【问题讨论】：

能否解释一下问题3中的“共享属性”和“冗余验证码”是什么？
关于共享属性：在有界上下文实现（Recipient 和Payer）中，客户实体上都存在的属性。即Name。关于冗余验证：由于模型应该具有丰富的实现（自我验证和不变安全），因此两个实体中的 Name 属性都会存在验证。

【解决方案1】：

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

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

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

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

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

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

【讨论】：

【解决方案2】：

答案：

1.如果聚合及其存储库是只读的，则是。如果一个人在不通知其他人的情况下单独更改架构或数据，那么在有界上下文之间共享存储和架构可能是一个问题，但我认为在这种情况下这不是一个大问题。

但如果收款人和付款人是可编辑的，情况就不同了。有可能人们可以修改它们，这会导致跨界上下文的影响。例如，客户可能需要更改特定发货订单的地址，但共享切割表可能会更改客户发货订单的所有地址，恕不另行通知。所以最好为它们使用不同的存储空间。

2.不同的限界上下文需要客户的不同方面。我认为只依赖必要的数据是一种很好的做法，因此聚合抽象可能会有所不同。潜在的可维护性问题可能发生在实现端（主要是重复代码）。所以我们可能会引入一个额外的组件来返回客户的所有方面，并在其上构建有界上下文特定的适配器。

【讨论】：