Get best of the week

Por que o Event Sourcing é o antipadrão para a interação de microsserviços

Olá de novo. Em março, a OTUS lança o próximo fluxo do curso de Arquiteto de Software . Antecipando o início do curso, preparamos uma tradução de material útil para você.



Recentemente, as arquiteturas orientadas a eventos (arquiteturas orientadas a eventos) e, em particular, o Event Sourcing (a geração de eventos) se espalharam. Isso é motivado pelo desejo de criar sistemas modulares sustentáveis ​​e escaláveis. Nesse contexto, o termo "microsserviços" é frequentemente usado. Na minha opinião, os microsserviços são apenas uma das maneiras de implementar um " Contexto Limitado ". É muito importante definir corretamente os limites dos módulos, e o Design Estratégico , descrito por Eric Evans no Design Orientado a Domínios, ajuda nisso . Ele ajuda a identificar / detectar módulos, limites ("contexto restrito") e a descrever como esses contextos se relacionam (mapa de contexto, ContextMap).

Eventos de domínio como base de um único idioma


Embora isso não esteja explicitamente indicado no livro de Eric Evans, os eventos de domínio contribuem muito bem para os conceitos de DDD. Práticas como o assalto a eventos Alberto Brandolini muda o foco dos eventos do nível técnico para o organizacional e de negócios. Aqui não estamos falando de eventos da interface do usuário, como clicar em um botão (ButtonClickedEvent), mas de eventos do domínio que fazem parte da área de assunto. Eles são discutidos e compreendidos por especialistas da área. Esses eventos são os conceitos principais e ajudam a formar um idioma único (linguagem onipresente ), com a qual todos os participantes (especialistas no assunto, desenvolvedores etc.) concordarão.

Eventos de domínio usados ​​para se comunicar entre contextos


Eventos de domínio podem ser usados ​​para interagir entre contextos restritos. Suponha que tenhamos uma loja online com três contextos: Pedido (entrega), Entrega (entrega), Fatura (conta).

Considere o evento "Pedido aceito" no contexto do pedido. O contexto da fatura, bem como o contexto da entrega, estão interessados ​​em rastrear esse evento, pois esse evento aciona alguns processos internos nesses contextos.

O mito da fraca conectividade


O uso de eventos de domínio ajuda a desenvolver módulos fracamente acoplados. Módulos individuais podem não estar disponíveis temporariamente. Mas para um evento de domínio, não é absolutamente importante se eles estão disponíveis ou não, pois o evento descreve apenas o que aconteceu no passado. Outros módulos decidem quando processar o evento. Você obtém um sistema flexível por padrão.

Além da dissociação do tempo, os eventos do domínio oferecem outra vantagem: o contexto do pedido não precisa saber que o contexto das faturas e da entrega escuta seus eventos. De fato, ele nem precisa saber que esses contextos existem.

É ótimo, mas a dificuldade está em decidir quais dados armazenar no evento?

A resposta simples: fornecimento de eventos!


Os eventos são úteis, por que não usá-los ao máximo. Essa é a idéia principal do Event Sourcing . Você armazena o estado da unidade não através da atualização de seus dados (CRUD), mas através do uso de um fluxo de eventos.
Além do fato de poder executar eventos e obter status, há outro recurso do Event Sourcing: você obtém um log de auditoria completo gratuitamente. Portanto, quando esse registro for necessário, ao escolher uma estratégia de armazenamento, preste atenção ao Event Sourcing.

Event Sourcing é apenas uma camada de armazenamento


Pode parecer estranho para você que eu mudei imediatamente de eventos de domínio para armazenamento, pois, obviamente, esses são conceitos de níveis diferentes.

... e aqui está o meu ponto: Event Sourcing é uma solução local usada em apenas um contexto limitado! Os eventos de Event Sourcing não devem ser retirados para o mundo exterior! Outros contextos limitados não precisam saber como os dados uns dos outros são armazenados e, portanto, não importa se algum contexto usa o Event Sourcing.

Se você usar o Event Sourcing globalmente, divulgará seu nível de armazenamento.

O método de armazenamento de dados se torna sua API pública. Sempre que você fizer alterações na camada de armazenamento, precisará lidar com uma alteração na API pública.

Estou certo de que todos concordarão que isso é ruim quando vários contextos limitados compartilham dados em um banco de dados (relacional) devido à conectividade resultante. Mas como isso é diferente do Event Sourcing? Nada. Não importa se você usa eventos compartilhados ou tabelas compartilhadas no banco de dados. Nos dois casos, você compartilha os detalhes de armazenamento.

Existe uma saída


Ainda argumento que os eventos de domínio são ideais para interagir entre contextos limitados, mas esses eventos não devem estar relacionados aos eventos usados ​​para o Event Sourcing.

A solução proposta é muito simples: independentemente da abordagem usada para armazenar dados (CRUD ou Event Sourcing), você publica eventos de domínio no armazenamento de eventos global. Esses eventos representam a API pública do seu contexto. Ao usar o Event Sourcing, você armazena eventos do Event Sourcing em sua loja local, acessível apenas para esse contexto limitado.

liberdade de escolha


Ter eventos de domínio separados na API pública permite modelá-los de forma flexível. Você não está limitado a um modelo predefinido pelo Event Sourcing.

Existem duas opções para trabalhar com “eventos do mundo real”: um Serviço de Protocolo Aberto e um Idioma Público (Serviço de Host Aberto, Idioma Publicado) ou um Cliente / Fornecedor.

Serviço com um protocolo aberto e um idioma público (Open Host Service, Idioma Publicado)


Apenas um evento de domínio é publicado que contém todos os dados que outros contextos limitados podem precisar. Na terminologia DDD, isso pode ser chamado de Serviço de Host Aberto e Idioma Publicado.



O início do evento no mundo real "Pedido aceito" leva à publicação de um evento de domínio OrderAccepted . A carga útil desse evento contém todos os dados do pedido que outros contextos restritos podem precisar ... portanto, esperamos que os contextos de fatura e entrega encontrem todas as informações necessárias.

Fornecedor do cliente


Para cada consumidor, eventos separados são publicados. É necessário coordenar os modelos de cada evento com apenas um consumidor; não é necessário determinar um modelo compartilhado comum. DDD chama esse relacionamento de Cliente / Fornecedor.



A ocorrência de eventos do mundo real "Pedido aceito" leva à publicação de eventos individuais para cada um dos consumidores: InvoiceOrderAcceptede DeliveryOrderAccepted. Cada evento de domínio contém apenas os dados necessários para o contexto do destinatário.

Não quero discutir os prós e contras dessas abordagens agora. Eu só quero chamar a atenção para o fato de que você pode escolher o número de eventos do domínio e os dados que eles armazenam.

Essa é uma vantagem que você não deve subestimar, porque você pode decidir como desenvolver a API do seu contexto limitado sem estar vinculado a eventos do Event Sourcing.

Conclusão


A exposição de peças de armazenamento é um anti-padrão bem conhecido. Falando em armazenamento, pensamos principalmente em tabelas de banco de dados, mas vimos que os eventos usados ​​para o Event Sourcing são apenas outra maneira de armazenar dados. Portanto, distribuí-los também é um anti-padrão.


Tradução: "um bom desenvolvedor como um lobisomem tem medo de balas de prata".

O Event Sourcing é uma abordagem poderosa se usada corretamente (localmente). À primeira vista, parece que para arquiteturas orientadas a eventos isso é uma bala de prata, mas se você olhar atentamente, poderá ver que essa abordagem pode levar a uma conexão forte ... o que, obviamente, você não deseja.

Referências


Além da minha experiência pessoal, recebi muita inspiração de vários artigos e conferências. Gostaria de mencionar a apresentação de Eberhard Wolff “Arquitetura e implementações baseadas em eventos com Kafka e Atom” (arquitetura e implementação de eventos usando Kafka e Atom). Especialmente sobre o Event Sourcing e o que são eventos , o que é muito relevante no contexto deste post. O exemplo da loja online também foi inspirado por essa palestra.

Se você quiser obter mais informações, consulte estes recursos:


: « : ».

More articles:


All Articles