3

我找到了这个代码示例。

https://code.google.com/p/ddd-cqrs-sample/

看起来非常完整且组织良好。不是“框架”，只是一个具有非常精细和明确的做事方式的示例项目。但是，不完整。这带来了一些疑问。

他们擅长回答你的问题。在https://groups.google.com/forum/#!forum/ddd-cqrs-sample查看他们的 google 组

好的。问题是他们在 SALES BC 中有客户，在 CRM BC 中有客户/潜在客户。我想我们都同意指向同一个“人”。假设在销售漏斗中，此人从销售线索开始，然后通过购买使他成为客户的东西成为客户。

我的问题是，为什么他们对同一个“人”有三个不同的表示？它不能像“共享内核聚合”吗？我不知道这样的事情是否存在。在数据库 Client/Customer/Leads 中有三个表用于相同的“事物”，这让我有点困扰。另外，在示例中不清楚（未实施 CRM）您如何在 BC 之间进行通信。我阅读了他们的文档，但找不到任何有价值的线索。

那过程会怎样？假设您需要将此潜在客户/客户/客户添加一个地址来运送订单。你会选择哪一个？我猜是 Shipping BC 中的 ShippingAddress 吗？用 Id 指向？顾客？客户？您是否应该将地址直接添加到客户？以直邮为例，因为它与航运无关？

4

3 回答 3

5

共享内核在 CRM 和 Sales BC 之间引入了非常紧密的耦合。

这是一个替代方案..

CRM BC拥有客户。您不必在 Sales BC 中复制完整的客户 AR。这避免了必须处理双向同步。您可以让 Sales BC 中的 Client AR 通过其标识符引用 CRM BC 中的 Customer AR，然后将特定的 Client 属性封装在 Sales BC 中。这在 Sales 和 CRM BC 之间创建了顺从者或客户-供应商关系，其中 Sales BC 位于下游，CRM BC 位于上游。CRM 上下文可能会使用开放主机服务使客户 AR 可用于销售 BC。

于 2013-07-29T08:09:36.667 回答
4

通常不鼓励跨上下文重用。在极少数情况下共享内核可以提供帮助，但通常域对象（及其聚合）应保持在其各自上下文的本地。否则，您将引入紧密耦合并失去有界上下文的主要优势之一。他们将无法相互独立地改变和发展。

于 2013-07-29T17:14:31.910 回答
1

有界上下文通常由不同的团队和不同的客户实施（例如销售部门和客户关系部门）。他们对客户都有自己的看法，我认为该项目试图通过不同的命名来夸大这一点。

于 2013-07-29T05:51:01.127 回答