为了提问，假设我有 2 个微服务。
我知道每个微服务不应该紧密耦合，它应该有自己的数据库。
假设会计有发票，每张发票都有开具代理。 来自会计的代理也作为身份微服务中的用户存在。
如果我理解得很好，应该将来自身份管理（用户）的数据复制到会计（代理），并且应该只复制该有界上下文所需的数据（名字和姓氏），以便发票可以有适当的issuingAgentId.
这是保持数据一致并在上下文之间共享的正确方法吗？ 每次在身份微服务中创建用户时，都会发布“UserCreated”事件，并且会计或任何其他对此事件感兴趣的服务应该通过添加相应的代理来监听和处理它？ 更新用户信息也是如此。
【问题讨论】：
标签： domain-driven-design microservices consistency
这是处理它的一种方法，是的，通常是首选方法。您在服务中本地保留一个缓存，该缓存保存来自另一个服务的数据副本。在事件驱动系统中，这将涉及监听感兴趣的事件并使用它们来更新本地缓存。缓存可以在内存中，也可以持久存在。您的用例的一个示例是在开具发票时，会计上下文将在创建发票之前在其本地缓存中查找用户/代理 ID。
其他选项：
共享数据库
我知道它不受欢迎（有充分的理由），但您始终可以共享数据库架构。例如，Identity 上下文可以写入用户表，而 Accounting 上下文可以在需要 AgentId 放入发票时从中读取。权衡是您在数据库级别进行耦合，并引入单点故障。
RPC
您可以在需要信息时对另一个服务进行 RPC 调用。在您的示例中，会计上下文将在开具发票之前调用 AgentId/用户信息的身份管理上下文。这种方法的权衡再次是与其他服务的耦合。当它不可用时你会做什么？您不能开具发票。
报告域
另一种选择是拥有一个完全独立的服务来监听来自其他服务的数据并维护 UI 的视图模型。这将使您的其他服务不知道其他服务的担忧。使用事件驱动系统时，您将监听来自其他服务的事件，这些服务允许您为 UI 构建视图模型。如果您所做的只是查看数据，这通常是一个不错的选择
【讨论】：