我找到了这个代码示例。
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指向？顾客？客户？您应该直接将地址添加到客户吗？例如直邮，因为它与Shipping无关？
答案 0 :(得分：6)
共享内核在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。
答案 1 :(得分：5)
通常不鼓励跨上下文重用。可能在极少数情况下共享内核可以提供帮助，但通常域对象（及其聚合）应保持在其各自上下文的本地。否则你会引入紧耦合并失去有界上下文的一个主要优点。他们将无法独立改变和发展。
答案 2 :(得分：1)
有限的上下文通常由不同的团队和不同的客户（在销售部门和客户关系部门的示例中）实施。他们都会对客户有自己的看法，我认为该项目试图通过不同的方式来夸大这一点。