让我们假设我有身份管理有限的上下文和讨论有界的上下文。每个都是一个单独的微服务。
身份有用户，讨论有版主。
如果我在身份界限上下文中更新名字和姓氏，我的计划是向Amazon SQS发布消息，并讨论有限上下文以侦听该队列的任何更改，并通过讨论上下文更新名字和姓氏反腐败层。
我的问题是，如果我决定在讨论BC中更改名字和姓氏怎么办？我的身份BS是否应该听取这些更改，或者双向通信不被认为是一种好的做法，我应该始终在Identity BC内部更新这些信息？
答案 0 :(得分：2)
人们如何更改姓名？
我会尝试在允许的地方有一个地方，并让该上下文拥有数据。然后，其他上下文可以订阅更改并采取相应的行动。
答案 1 :(得分：2)
我的身份BS是否应该听取这些更改，或者双向通信不被认为是一种好的做法
我认为双向沟通不一定是这里的问题。我担心的是，你似乎有两个不同的BC充当了记录和＃34;为了身份。
在blue book中，埃文斯写的有界语境是由意义定义的;当您从一个上下文跨越到另一个上下文时，您可能需要更改对常用术语所理解内容的理解：它不一定遵循一个上下文中聚合的规则（用户？）将是相同的和另一个一样。
给定的例子，用户，可能更加抽搐 - 因为现实世界而不是模型可能是记录簿，而且＃34;聚合＆＃34;真的只是一个愚蠢的数据包。
如果我只使用引用ID，那么这意味着，讨论BC将不会在其域中包含必要的数据
需要什么？记录讨论书中的更改是否取决于存储在记录身份簿中的数据？
示例，在身份上下文中我有用户名，姓名和姓氏等，但在讨论上下文中，我可能有相同的用户，但表示为主持人或海报，只有该BC的必要属性。如果身份上下文中的名称发生更改，则应将该更改传播到讨论中。
听起来好像是在描述读取所必需的;好像你有一个讨论的视图，其中包括参与者的代表，包括他们的角色（存在于BC讨论中）及其身份。
读取往往不是一个非常有趣的用例，因为读取不会改变记录簿。正如Udi暗示的那样，为了构建视图，您基本上需要一个引用ID，您可以使用它来从一些键值存储中提取您想要的数据。有没有理由更喜欢KV商店是这个 BC的一部分而不是那个一个？
消费者可能是第三方公司和我们公司。
直接连接到微服务，或者代替使用api作为支持微服务的外观？