为了提问，我们说我有2个微服务。
我知道每个微服务都不应该紧密耦合，它应该拥有它自己的数据库。
我们说会计有发票，每张发票都有发票代理。 来自会计的代理也作为用户身份微服务存在。
如果我理解得当，来自身份管理（用户）的数据应该被复制到会计（代理），并且应该只复制该有界上下文（名字和姓氏）所需的数据，因此发票可以有适当的issuingAgentId。
这是保持数据在上下文之间保持一致和共享的正确方法吗？ 每次在身份微服务中创建用户时，事件＆＃34; UserCreated＆＃34;将发布和会计或任何其他对此事件感兴趣的服务应该通过添加相应的代理来收听和处理它？ 同样适用于更新用户信息。
答案 0 :(得分：0)
这是处理它的一种方法，通常是首选方法。您在服务中本地保留一个缓存，其中包含来自其他服务的数据副本。在事件驱动的系统中，这将涉及监听感兴趣的事件并使用它们来更新本地缓存。缓存可以是内存中的，也可以是持久的。您的用例的一个示例是在提取发票时，会计上下文会在创建发票之前在其中查找用户/ agentid的本地缓存。
其他选择：
共享数据库
我知道它是不受欢迎的（有充分理由），但您始终可以共享数据库架构。例如，Identity上下文可以写入用户表，并且当需要AgentId放入发票时，Accounting上下文可以从中读取。权衡是您在数据库级别进行耦合，并引入单点故障。
<强> RPC
您可以在需要信息时对其他服务进行RPC调用。在您的示例中，会计上下文将在提交发票之前调用AgentId / User信息的Identity Management上下文。通过这种方法进行权衡再次成为与其他服务的耦合。当它不可用时你会怎么做？你不能提出发票。
报告域
另一个选择是拥有一个完全独立的服务，该服务侦听来自其他服务的数据并维护UI的视图模型。这将使您的其他服务不了解其他服务的顾虑。使用事件驱动的系统时，您可以从其他服务中侦听事件，这些服务允许您为UI构建视图模型。如果您正在查看数据
，这通常是一个不错的选择