O documento discute o uso de sagas, NServiceBus e RabbitMQ para lidar com fluxos de trabalho complexos. Ele explica como sagas podem orquestrar tarefas entre agregações para implementar casos de uso de negócios, como persistir estado e disparar eventos. O documento também discute benefícios de arquiteturas CQRS e como NServiceBus e RabbitMQ podem ser usados para comunicação assíncrona entre domínios e camadas.

1. Lidando com fluxos complexos
com o uso de Sagas,
NServiceBus e RabbitMQ

2. Heber Ortiz Pereira
twitter.com/heberortiz
youtube.com/donetbr
fb.com/donetbr
github.com/heberop
• Arquiteto de Software @ Agile Content (UUX)
• Desenvolvedor (20 anos)
• Mágico amador

3. Revisitando - DDD

4. Domain Services
Implementa a lógica de domínio que não está
diretamente associada a uma agregação e geralmente
afeta várias entidades

5. Domain Services
Coordena a atividade de agregações e repositórios com
o propósito de implementar uma ação de negócio

6. Domain Services
Pode consumir serviços de infraestrutura, como enviar
emails

7. Domain Services
As ações de um domain service vem dos requirements e
são aprovados pelo domain expert
linguagem ubíqua

8. Eventos
O código não precisa ficar em um único
lugar
O disparo do evento é totalmente
desacoplado do tratamento do evento
Vários tratamentos (handlers) para o
mesmo evento em vários lugares

9. Um evento é uma classe

10. Disparando o Evento

11. Bus
Parte da infraestrutura
Notifica os listeners do evento
Bastante flexível
Pode gravar os eventos
Pode ter vários handlers
BUS

12. Bus
MassTransit
Rebus
NServiceBus
BUS

13. NServiceBus
Transporte
RabbitMQ
Azure Service Bus
MSMQ
SQL Server
Persistencia
RavenDB
Nhibernate
Azure Storage

14. RabbitMQ
Message Broker
Advanced Message Queuing Protocol
(AMQP)
Open Source
https://www.rabbitmq.com/

15. Arquiteturas
Clássica
•Command
•&
•Query
Domain
Layer
Nova
Command
Stack
Domain
Layer
Query
Stack
DTO
+
Data
Access

16. Boa para comandos
Precisa de ajustes para persistência
Expõe comportamento na presentation layer

17. Boa para queries
Não possui regras de negócio
Risco de estar em estado inválido

18. Presentation layer
Application layer
Infrastructure layer
Domain layer
Presentation layer
Infrastructure layer
Domain layer
Application
layer Data Access
+
DTO
commands queries
Arquitetura em Camadas CQRS

19. Benefícios
Simplificação do design
Potencial para escala aprimorada

20. Bancos Separados?

21. Sincronização

22. Mensagens

23. Mensagens

24. Mensagens

25. Handlers

26. Saga
“Saga é um componente lógico no qual desenvolvedores
destilam peças de lógica de negócios. Mais
precisamente, a saga (em cooperação com o bus)
orquestra todas as tarefas que precisam ser realizadas
para implementar um caso de uso”
Dino Esposito, Architecting Applications for the Enterprise

29. Saga
•Pode ser um Guid
•Pode ser o ID da agregação da qual se trata a saga
•Pode ser uma combinação de valores que é único no contexto
Sagas precisam ser identificadas por
um único ID
•Persistência é responsabilidade do Bus
•Estado de agregações associadas devem ser persistidas
Sagas podem ser persistidas
•Mero executor de tarefas obtendo qualquer dado do
comando que inicia a sagaSagas podem ser stateless

30. Como estender a solução?
Escreva uma nova Saga
Escreva um novo Handler
Registre no Bus

31. Referências
Architecting Applications for the
Enterprise, Dino Esposito
Patterns, Principles, and Practices of
Domain-Driven Design, Scott Millett
Pluralsight
Scaling Applications with Microservices,
MassTransit, and RabbitMQ
Scaling Applications with Microservices
and NServiceBus

32. Dúvidas?
twitter.com/heberortiz
youtube.com/donetbr
fb.com/donetbr
github.com/heberop
bit.ly/uux-vagas