这个问题是相关的，但比这个问题更具体。
我将在这里使用一个简单的例子。假设我们User在一个上下文中有一个Customer实体，在另一个上下文中有一个实体。这是同一实体的两种不同表示。
假设User和Customer都有一个电子邮件地址，但电子邮件地址总是通过User所属的有界上下文更改。因此，用户上下文是电子邮件地址的真实来源。所以理想情况下，我希望上下文中的电子邮件地址从客户上下文的角度来看Customer是不可变的。
因此，当在用户上下文中更改电子邮件地址时，EmailAddressChanged会发出一个事件。这可以; 我订阅了Customer上下文中的事件。但是，我现在需要通过更改Customer电子邮件地址来处理此事件。所以我需要某种命令方法来进行这种改变。
User除了从上下文处理事件时，如何确保不使用命令方法？
如果我在两种情况下都允许突变，那么它们都会成为事实的来源，我需要将事件和处理程序的数量增加一倍，以确保信息在两种情况下保持一致
也许这些有限的上下文之间存在隐藏的客户/供应商关系？如果Userbc 是 bc 的真实来源Customer，那么Userbc 可能会公开一个 API 以供下游上下文访问（Customer也许还有更多？）。在您的问题中，您说只有电子邮件地址应该是“不可变的”并且取决于User上下文 - 但是，我认为这可能暗示整个Customer上下文是上下文的消费者/客户，User并且应该使用其公共 API（不应该暴露内部用户直接领域模型 - 需要一些外观类来隐藏细节）。
如果不是这种情况，并且上下文之间没有这种关系 - 您可以使用Customerbc 中的专用组件来更改数据库，而无需直接调用域方法。然后，存储库可用于查询客户并使用更新的电子邮件地址重新创建他们。我的观点是——如果你想让客户 bc 应用EmailAddressChanged事件，你显然需要一些东西来改变数据库，但你不需要通过域方法来做到这一点。应用事件的组件将是上下文EmailAddressChanged基础设施层的一部分。Customer如果您使用此解决方案，则不存在通过业务案例场景修改客户的风险。
顺便说一句，您Customer实际上不是一个专门的User上下文阅读模型吗？