Event Storming na prática

No último artigo, compartilhei os meus conhecimentos da técnica de Event Storming, entretanto, ficamos apenas na teoria.

Como prometido, aqui está a segunda parte dessa série que estou desenvolvendo sobre como: iniciar, desenvolver e finalizar um projeto de forma assertiva.

O tema de hoje ainda envolve Event Storming, mas quero deixá-lo mais divertido: vamos ver, na prática e do ponto de vista de um Arquiteto que está conduzindo o entendimento de um determinado problema, como se desenrola a construção da solução.

Para isso, preparei para vocês a modelagem da solução de negócio usando Event Storming, baseada em um problema de um serviço financeiro. Me inspirei em um desafio técnico que encontrei nesse repositório do GitHub sobre um sistema de transferência e depósito de dinheiro entre dois tipos de usuários — comuns e lojistas — que precisam cumprir algumas regras de negócio para utilizar os recursos do sistema.

Dito, isso e já com o conhecimento do que é o Event Storming e como trabalhar com essa metodologia, vamos então colocar o cérebro para raciocinar e criar a jornada de negócio desse sistema.

Requisitos de negócio

Os requisitos de negócio necessários para o funcionamento desse sistema são os seguintes:

• O sistema é feito para permitir depósito e transferências de dinheiro
• O sistema pode ter dois tipos de usuários: comuns e lojistas
• Ambos os usuários precisam ter um cadastro com dados como: documento (CPF/CNPJ), email e senha. Sendo o email e o documento obrigatoriamente únicos por usuário.
• Apenas usuários comuns podem transferir dinheiro
• Caso um erro ocorra na transferência , o dinheiro deve permanecer na conta do usuário que estava transferindo.
• O usuário comum que vai transferir o dinheiro, precisa ter saldo positivo na carteira
• Usuário que recebeu a transferência, precisa ser notificado

Explicando o desenho arquitetural:

O desenho arquitetural do event storming não entra em muitos detalhes, pois seu objetivo é fornecer uma visão mais ampla das regras de negócio. Ele costuma focar no “caminho feliz”, ou seja, no resultado final esperado. No entanto, é possível destacar hot spots (pontos de atenção) para discutir posteriormente como determinadas regras de negócio devem ser tratadas, principalmente os possíveis tratamento de erros.

Antes de adentrar no fluxo, deixo aqui uma legenda dos significados de cada card para que fique fácil identificar o que é cada card e o que ele representa no desenho.

OBS: Esse é o mesmo desenho que expliquei no artigo anterior, é importante que leia o outro artigo para entender o que cada um significa.

1. Fluxo de identificação do usuário e processo de criação de conta

Nesse diagrama, podemos ver o fluxo de como é esperado que um usuário se identifique e em que momento essas informações se correlacionam para gerar comandos e eventos de criação do usuário e da conta bancária.

O processo inicia com o envio dos dados de cadastro e tipo de usuário, passa pelas regras de criação no agregado User, e finaliza com a geração dos eventos USER CREATED e ACCOUNT CREATED, que indicam a criação bem-sucedida do usuário e de sua conta.

User Identification and Account Creation Process Diagram

O que esse diagrama diz:

User → Representa o ator que inicia o processo de criação de conta.

É quem deseja se cadastrar no sistema para posteriormente realizar ações como depósitos e transferências.

Sign Up View → É a interface de entrada (view) que permite a interação com o sistema.

Pode ser um site, aplicativo móvel, API, Postman, ou chatbot, por onde o usuário envia seus dados de cadastro.

INSERT USER DATA AND CHOICE TYPE OF USER → É o comando que representa a ação de inserir os dados obrigatórios do usuário (e-mail, nome completo, senha, documento) e escolher o tipo de usuário (comum ou comerciante).

COMMON / SHOPKEEPER → São as views específicas que aparecem conforme o tipo de usuário escolhido.

• COMMON → fluxo para usuários comuns (pessoas físicas).
• SHOPKEEPER → fluxo para comerciantes (pessoas jurídicas).

User (Agregado) → Aqui, o bloco User deixa de representar o ator e passa a representar o agregado de domínio responsável pelas regras e consistência dos dados do usuário.

Esse agregado recebe comandos e lança eventos relacionados à criação de usuários.

CREATE USER WITH REQUIRED FIELDS → É o comando de criação de usuário dentro do domínio.

Ele encapsula os dados validados e inicia o processo de persistência na base de dados.

USER CREATED → É o evento de domínio emitido pelo agregado de usuário quando o cadastro é criado com sucesso.

Esse evento informa outras partes do sistema (por exemplo, o agregado de conta) de que o usuário foi criado.

ACCOUNT (Agregado) → Representa o agregado responsável pela conta bancária do usuário.

Ele é acionado após o evento USER CREATED, pois toda conta precisa estar associada a um usuário válido.

CREATE USER ACCOUNT → É o comando de criação da conta bancária do usuário recém-criado.

Pode incluir dados como número da conta, saldo inicial e vínculo com o ID do usuário.

ACCOUNT CREATED → É o evento de domínio emitido após a criação bem-sucedida da conta.

Indica que o usuário agora possui uma conta ativa no sistema e está apto a realizar operações financeiras (depósito, transferência, etc.).

2. Fluxo de Depósito

Nesse diagrama, podemos ver o fluxo de como o usuário realiza um depósito em sua conta, e em que momento essa ação gera comandos e eventos de domínio relacionados ao processo de depósito.

O usuário insere os dados necessários na view; a entidade DEPOSIT processa as regras de negócio (validações, consistência e interação com persistência/provedores) e através do agregado de ACCOUNT emite eventos como ACCOUNT DEPOSIT CREATED, ACCOUNT DEPOSIT SUCCEEDED ou ACCOUNT DEPOSIT FAILED.

Esse fluxo também evidencia a necessidade de definir qual será o comportamento do sistema em caso de falha (retry, notificação, reversão, auditoria)

Deposit Process Diagram

O que esse diagrama diz:

User → Representa o ator que inicia o processo de depósito.

É quem deseja adicionar um valor à sua conta bancária dentro do sistema.

Account Deposit View → É a view responsável por receber os dados do depósito.

Pode ser uma tela do app, um formulário web, ou uma interface de API. É onde o usuário insere os valores e confirma a operação.

INSERT DEPOSIT REQUIRED DATA → É o comando que representa a ação de inserir todos os dados obrigatórios para efetuar o depósito (ex.: valor, conta de origem, método de pagamento, etc.).

Esse comando é enviado para iniciar o processamento do depósito.

DEPOSIT → É a entidade responsável por coordenar o processo de depósito.

Ela executa as regras de negócio, garante a consistência da operação e gera os eventos de domínio correspondentes. Também é responsável por acionar a lógica principal (EXECUTE THE DEPOSIT LOGIC).

EXECUTE THE DEPOSIT LOGIC → É o comando interno que representa o momento em que a entidade DEPOSIT executa efetivamente as regras e interage com o agregado da conta.

Aqui ocorre a verificação de validade, saldo e integridade do processo.

ACCOUNT → É o aggregate responsável por manter o estado da conta e reagir às operações financeiras.

Ele recebe as intenções de depósito e gera os eventos adequados de acordo com o resultado da operação.

ACCOUNT DEPOSIT CREATED → É o evento de domínio que indica que o processo de depósito foi criado e iniciado com sucesso.

Serve como ponto de rastreabilidade do início da operação.

ACCOUNT DEPOSIT SUCCEEDED → É o evento de domínio que representa o sucesso da operação.

A conta foi atualizada corretamente e o valor foi creditado.

ACCOUNT DEPOSIT FAILED → É o evento de domínio que indica que a operação de depósito falhou.

Pode ocorrer por inconsistências, falhas externas ou problemas na validação de dados.

WHAT HAPPENS WHEN THAT FAILS? → É o hot spot do fluxo, um ponto que destaca a necessidade de definir o comportamento do sistema em caso de falha.

Aqui o time de domínio deve decidir o que acontece: reprocessar, compensar, notificar o usuário, ou gerar logs de auditoria.

3. Fluxo de Transferência

Nesse diagrama, podemos ver o fluxo de como um usuário comum realiza uma transferência, e como o sistema reage a essa operação com comandos, eventos e notificações.

Após o envio dos dados da transferência, o agregado TRANSFER processa a operação, gerando eventos como ACCOUNT TRANSFER CREATED, ACCOUNT TRANSFER SUCCEEDED e ACCOUNT TRANSFER FAILED.

Quando a transferência é concluída com sucesso, o serviço de notificação é acionado para avisar o usuário que recebeu o valor, garantindo o encerramento completo do fluxo.

Deposit Process Diagram

O que esse diagrama diz:

Common User → Representa o ator que inicia o processo de transferência.

É um usuário comum (não comerciante) que possui uma conta ativa e saldo suficiente para realizar o envio de valores. Apenas o usuário comum pode realizar transferencias.

Account Transfer View → É a interface de entrada (view) que permite ao usuário executar a operação de transferência.

Pode ser um aplicativo móvel, site web, API (Postman) ou outro canal capaz de enviar as informações da transferência.

INSERT TRANSFER REQUIRED DATA→ É o comando responsável por registrar a intenção de transferência.

Aqui o usuário fornece os dados obrigatórios:

• valor da transferência,
• conta de origem,
• conta de destino,
• documento do destinatário, etc.

TRANSFER → É a entidade que centraliza as informações da transferência.

Representa o registro inicial da operação, ainda sem aplicar regras de negócio. Serve como base para o próximo passo, onde o processamento é de fato executado.

HANDLE THE TRANSFER LOGIC → É o comando que executa a lógica principal da transferência.

Ele coordena a interação com o agregado ACCOUNT, aplicando validações como:

• saldo disponível,
• status da conta,
• tipo de conta,
• e restrições de envio entre determinados perfis.

ACCOUNT (Aggregate) → É o agregado raiz que controla o comportamento da conta no domínio.

Ele reage ao comando de transferência, altera o estado da conta e emite eventos de domínio conforme o resultado da operação.

ACCOUNT TRANSFER CREATED → É o evento de domínio emitido quando a solicitação de transferência é criada com sucesso.

Indica que o pedido foi validado e registrado, mas ainda não concluído.

ACCOUNT TRANSFER SUCCEEDED → É o evento de domínio emitido quando a transferência é efetivada com sucesso.

O valor foi debitado da conta do remetente e creditado na conta do destinatário.

NOTIFICATION SERVICE → Serviço externo e assíncrono que escuta o evento ACCOUNT TRANSFER SUCCEEDED.

É responsável por enviar notificações (push, SMS, e-mail etc.) informando o sucesso da operação.

Notify the user who receives the transfer → Representa a política de notificação aplicada ao evento de sucesso.

O destinatário é informado sobre o recebimento do valor, concluindo o fluxo positivo.

ACCOUNT TRANSFER FAILED → É o evento de domínio emitido quando a transferência falha.

Causas possíveis:

• saldo insuficiente,
• conta de destino inválida,
• erro interno de processamento, etc.

WHAT HAPPENS WHEN THAT FAILS? → Representa um hot spot (ponto de decisão futura) para definir o comportamento do sistema em falhas.

Possíveis ações:

• estornar valores parciais,
• notificar o usuário sobre o erro,
• registrar logs e eventos de auditoria,
• ou tentar reprocessar automaticamente.

Link do desenho da arquitetura do event storming

[embed]

Link

Referências

• https://www.eventstorming.com
• https://github.com/PicPay/picpay-desafio-backend