Como podemos manter a visão dos fluxos de negócios em arquiteturas orientadas a eventos?

5

Estou planejando configurar uma arquitetura orientada a eventos usando aplicativos Spring Boot que publicam e leem mensagens de um corretor Kafka.

Suponhamos que fosse um aplicativo de e-commerce com os eventos usuais (pedido efetuado, pagamento processado / com falha, reserva de item, disponibilidade sem estoque, pedido enviado e assim por diante).

No contexto do meu negócio, temo que isso possa acontecer:

The problem is that it can be hard to see such a flow as it's not explicit in any program text. Often the only way to figure out this flow is from monitoring a live system. This can make it hard to debug and modify such a flow. The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years. The pattern is still very useful, but you have to be careful of the trap.

De artigo de Martin Fowler O que você quer dizer com evento guiado

A questão é: como posso manter uma visão global do fluxo de negócios que acontece em uma arquitetura tão dissociada e rica em eventos?

    
por codependent 03.10.2018 / 09:30
fonte

2 respostas

5

The problem is that it can be hard to see such a flow as it's not explicit in any program text. Often the only way to figure out this flow is from monitoring a live system.

Existem dois aspectos separados para isso: como você centraliza a lógica de um fluxo e como você identifica os fluxos ao monitorar.

Para monitorar uma possível solução, use ID de correlação e causalidade . Todo evento é rotulado com um ID aleatório e exclusivo. O ID de correlação de um fluxo é o ID exclusivo do evento de origem e é copiado para um campo separado de cada evento sucessivo que faz parte desse fluxo. O ID de causalidade é o ID exclusivo do evento anterior no fluxo que levou diretamente ao evento atual, o que é útil para determinar a relação causativa entre os eventos. Conveniente nisso é que não há nenhum componente central que deve fazer a contabilidade de fluxos, pois somente a agregação de registros após o fato é necessária.

Paracentralizaralógicadofluxo,umasoluçãoestánousode sagas e gerentes de processo . A saga é um fluxo de longa duração em um sistema com eventos que abrange várias partes e possivelmente vários contextos limitados. O gerenciador de processos é um software que conecta as partes. Ele não implementa nenhuma lógica de negócios, mas apenas mapeia eventos em comandos para outras partes do sistema.

Aliás,hámuitomaisproblemasemsistemascomeventosdoqueemidentificarfluxos.Umrecursoútiléolivro CQRS Journey da Microsoft. Ele ilustra através de um sistema real o que são e como resolvê-los.

    
por 03.10.2018 / 10:14
fonte
1

Você pode confiar no Mapa de Contexto que oferece uma visão de alto nível dos contextos Delimitados e seus relacionamentos .

Em seguida, dentro de um contexto Bounded, você pode confiar no código para fornecer uma visão detalhada de como o sistema deve funcionar. Aqui você tem Aggregates, que processam o comando e emitem eventos. Então você tem Sagas / Process managers que coordenam os processos de negócios de nível mais alto, reagindo a eventos e enviando comandos para os Aggregates.

Depois, você pode ter uma visualização ao vivo de como as mensagens estão passando pelo sistema. Eu fiz algo assim no passado.

    
por 03.10.2018 / 09:50
fonte