微服务和有限上下文 [英] microservices and bounded contexts

问题描述

出于疑问，假设我有2个微服务.

For the sake of question, let's say i have 2 microservices.

• 身份管理
• 会计

我知道每个微服务都不应紧密耦合，而应该拥有自己的数据库.

I know that each microservice should not be tightly coupled and it should have it's own database.

让我们说会计有发票，每张发票都有开票代理. 来自计费代理的身份也以身份"微服务中的用户"身份存在.

Let's say that accounting has invoices and each invoice has issuing agent. Agent from accounting also exists as User in Identity microservice.

如果我理解得很好，则应将身份管理(用户)中的数据复制到会计(代理人)中，并且应该仅复制该绑定上下文所需的数据(名字和姓氏)，因此发票可以具有适当的名称. issuingAgentId.

If i understood well, data from identity management (users), should be copied to accounting (agents), and should copy only data which are needed for that bounded context (first and last name), so the invoice can have proper issuingAgentId.

这是保持数据一致并在上下文之间共享的正确方法吗? 每次在身份微服务中创建用户时，将发布事件"UserCreated"，并且对此事件感兴趣的计费或任何其他服务应通过添加相应的代理来监听和处理该事件? 更新用户信息也是如此.

Is this correct way to keep data consistent and shared between contexts? Each time when user is created in identity microservice, event "UserCreated" will be published and accounting or any other service interested in this event should listen and process it by adding corresponding agent? Same goes for updating user information.

推荐答案

这是一种可以解决问题的方法，通常是首选方法.您在服务中本地保留了一个缓存，该缓存保存了另一个服务的数据副本.在事件驱动的系统中，这将涉及侦听感兴趣的事件并使用它们来更新本地缓存.缓存可以是内存中的，也可以是持久的.您的用例的一个示例是在生成发票时，Accounting上下文会在创建发票之前在其本地缓存中查找用户/agentid.

This is one way to handle it yes and usually the preferred method. You keep a cache locally in your service that holds copies of the data from another service. In an event-driven system, this would involve listening to events of interest and using them to update your local cache. The cache could be in-memory, or persisted. An example for your use case would be when raising an invoice, the Accounting context would look in it's local cache for a user/agentid before creating the Invoice.

其他选项:

共享数据库

我知道(出于充分的理由)对此不屑一顾，但是您始终可以共享数据库模式.例如，Identity上下文可以写入用户表，而Accounting上下文可以在需要AgentId放入发票时从中读取数据.折衷方案是您要在数据库级别进行耦合，并引入单点故障.

I know it is frowned upon (for good reason) but you can always share a database schema. For example, the Identity context can write to a user table and the Accounting context can read from it when it needs an AgentId to put in an invoice. The trade-off is you are coupling at the database level, and introducing a single point of failure.

RPC

需要信息时，可以对另一个服务进行RPC调用.在您的示例中，计费"上下文将在生成发票之前为"AgentId/用户"信息调用身份管理"上下文.使用这种方法的权衡又是与其他服务的耦合.不可用时该怎么办?您无法开具发票.

You can make a RPC call to another service when you need information. In your example, the Accounting context would call the Identity Management context for the AgentId/User information before raising an invoice. Trade-off with this approach is again a coupling to the other service. What do you do when it is not available? You cannot raise an Invoice.

报告域

另一个选择是拥有一个完全独立的服务，该服务侦听来自其他服务的数据并维护UI的视图模型.这会使您的其他服务无视其他服务的顾虑.当使用事件驱动的系统时，您将在侦听来自其他服务的事件，这些服务允许您为UI构建视图模型.如果您要做的只是查看数据，通常这是一个不错的选择

Another option is to have a completely separate service that listens for data from other services and maintains view models for UIs. This would keep your other services ignorant of other service's concerns. When using an event-driven system, you'd be listening for events form other services that allow you to build a view model for the UI. This is usually a good option if all you are doing is viewing the data

这篇关于微服务和有限上下文的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！