DEV Community: Thiago Henrique

SAGA Pattern para microservices

Thiago Henrique — Thu, 17 Jun 2021 04:24:36 +0000

Hoje em dia sabemos que a utilização de microsserviços está bastante difundida em vários projetos e em várias empresas. E entre vários desafios que esse modelo arquitetural carrega, está o de lidar com consistência de dados em operações que envolvem mais de um serviço e possivelmente vários bancos de dados.

E dentro desse cenário de sistemas distribuídos, e com a necessidade de lidar com contexto transacional, temos um padrão que cai como uma luva, o SAGA Pattern.

Apesar de muitos já terem ouvido falar, talvez nem todos tenham compreendido. Porém, podemos afirmar que uma vez entendido, ao tentar implementá-lo podem surgir questionamentos e desafios.

Existe bastante material na internet sobre esse pattern, porém meu objetivo aqui é tentar contribuir de alguma forma para o seu bom entendimento.

Origem e conceito

Bom, a ideia original do SAGA surgiu na verdade em 1987 através de um paper de dois cientistas da computação da universidade de Princeton. Em sua concepção o objetivo era suportar transações ou operações de longa duração, o que eles deram o nome de LLTs (Long Lived Transactions).

Mais recentemente, as sagas foram aplicadas para ajudar a resolver problemas de consistência em sistemas distribuídos modernos - conforme documentado em um artigo de sagas distribuídas de 2015.

Desde então o SAGA evoluiu e passou a se encaixar bem em situações onde você precisa lidar com operações que envolvam diversos microsserviços que precisam apresentar alguma consistência nos dados.

Se no modelo monolítico você faz uma transação no banco e grava tudo, no modelo de microsserviços essa transação será "virtualizada" uma vez que a operação em si é composta por transações que acontecem em cada serviço participante.

A ideia é simples, é fazer com que cada microsserviço execute uma operação alterando sua base de dados . No final do processo todos estarão com suas bases de dados atualizadas e consistentes.

Se ocorrer alguma falha na execução do processo em algum serviço, esse processo faz com que ações compensatórias sejam executadas nos serviços que operaram antes.

Vale ressaltar aqui que não importa para o SAGA falhas condicionais ou parciais.

Deixa eu me explicar. Se em um sistema de e-commerce a falha acontece no serviço de payment devido o cartão do buyer estar inválido ou algo do tipo, o sistema ainda sim poderia tentar concluir a transação utilizando outros cartões que o cliente possa ter cadastrado na plataforma ou outras formas de pagamento disponíveis (aqui não entro no mérito se essa funcionalidade faz sentido ou não).

Só após esgotadas todas as tentativas do sistema concluir a transação ele deve “avisar” aos demais para dar início às ações compensatórias. O padrão SAGA se interessa por sucesso definitivo ou falha definitiva.

SAGA também pode ser mais um nome dado para consistência eventual. Mas de certa forma ele expõe a ferida, no sentido que temos que pensar em um tratamento caso as operações do seu sistema não tenham sucesso, que seria as ações compensatórias.

Então se pudesse resumir o padrão em uma frase e de forma bem informal, caberia dizer que é basicamente um conceito de pilha, porém com uma funcionalidade de “Desfazer (CTRL+Z)”.

E, obviamente, sempre que se fala em SAGA precisamos falar sobre as duas estratégias que existem para sua implementação (Orquestração e coreografia).

Orquestração

No modelo orquestrado existe um componente central que se encarrega de acionar todos os serviços que fazem parte de uma SAGA. Caso sucesso, o agente ativa o próximo serviço. Caso falhe, esse agente orquestra as ações compensatórias. Esse componente é também conhecido como Saga Execution Coordinator (SEC).

Nesse modelo se tira dos microsserviços o conhecimento sobre o fluxo. Existe um outro componente que conhece o fluxo e vai coordenar a execução da operação de modo que os microsserviços vão se concentrar em fazer suas operações.

Aqui não devemos nos prender em uma estratégia de comunicação sempre síncrona. É bastante comum o uso de um Message Broker dando suporte ao fluxo possibilitando que os serviços sejam acionados ao receberem uma mensagem de um tópico que lhe interessa e poste de volta um novo evento como resultado da sua execução. Esse evento disparado permite que o orquestrador acione o próximo processo a ser executado.

Vale ressaltar também que o agente orquestrador pode ser usado como uma espécie de máquina de estado das diversas SAGAS que passam por ele.

Tá, mas nem tudo são flores! Algumas questões podem vir à nossa mente sobre os desafios que essa estratégia trás. Alguns deles seriam:

E se um step da saga demorar demais para ser executado?

Pode acontecer o que o seu negócio precisar que aconteça! Seu sistema pode trabalhar com um tempo de timeout que cancela a operação e a partir daí pode-se executar retentativas ou consultar o serviço chamado para saber se a operação foi concluída antes de realizar algum tipo de reprocessamento ou início de ações compensatórias. Aqui quem manda é o negócio!

Para a abordagem orquestrada, ao usarmos ela, não estaríamos criando um single point of failure?

Acredito que é preciso pensar na criticidade disso e principalmente ter maneiras de saber que sua SAGA foi interrompida. Por isso, considero que é ideal utilizar um serviço de mensageria para ter o registro da mensagem para ser trabalhada. Talvez não tentar fazer com que o erro seja impossível mas que quando aconteça, que ele seja visível.

Além disso, pode ser legal utilizar a "máquina de estado" do orquestrador para sabermos em que estado ele estava quando houve a falha.

Será que sempre conseguiríamos fazer o orquestrador ser de fato apenas um orquestrador?

É um ponto de atenção importante pois vejo um grande risco de termos anomalias no desenho da solução. O modelo orquestrador pode até ser mais “agradável aos olhos”, mais "visual". Porém com o passar do tempo pode receber regras de negócio que não deveria. Regra de negócio dos microsserviços “vazando” para o orquestrador.

Existe, entre outros, um framework em Java que propõe uma implementação do padrão SAGA para microsserviços em Java utilizando a estratégia orquestrada com JDBC/JPA e Spring Boot/Micronaut: Lib Eventuate Tram

Coreografia

Essa outra estratégia é baseada em eventos. Cada “bailarino”, ou cada serviço sabe qual evento disparar e qual evento ouvir para que a saga seja completa. Caberá a cada serviço "avisar" ao seu sucessor que conseguiu realizar a operação com sucesso ou ao seu antecessor caso ocorra alguma falha.

Já de antemão, essa abordagem possui a vantagem de não introduzir um ponto único de falha, já que as responsabilidades são distribuídas entre os participantes do Saga.

A própria utilização de um mecanismo de mensageria já traz consigo algumas boas possibilidades de resiliência como retentativas caso haja qualquer tipo de indisponibilidade em algum serviço no meio do processo, por exemplo.

Além disso, essa estratégia pode se encaixar bem para fluxos de trabalho simples que exigem poucos participantes e não precisam de uma lógica de coordenação.

Mas novamente, não existe solução perfeita. Podemos citar algumas fraquezas desse modelo como por exemplo:

Risco de dependência cíclica entre os participantes do Saga porque eles precisam consumir os comandos uns dos outros;
Quanto maior os passos, mais difícil o tracking do caminho por onde acontece a execução da SAGA;
O fluxo de trabalho pode ficar confuso ao adicionar novas etapas, pois é difícil controlar quais participantes do Saga ouvem quais comandos.

Qual a mais adequada?

Aqui vale a tão famosa resposta: Depende!

A decisão de qual estratégia utilizar vai depender muito da característica que seu negócio possui, além da expertise do time para implementar o pattern e também das ferramentas disponíveis para suportar tal abordagem.

Outros pontos importantes a serem considerados

Existem SAGAS onde as operações ocorrem em paralelo. Não necessariamente precisam ser sequenciais;
Para incluir um sistema em uma SAGA, não é algo tão trivial. Seu método, operação ou transação precisa ser reversível;
Tempo de duração: Uma SAGA pode demorar alguns segundos ou pode demorar mais tempo como alguns dias, dependendo da característica do seu sistema.

Cenários com as ações compensatórias

Compartilho aqui questionamentos ou cenários que imaginei enquanto me aprofundava sobre o tema das ações compensatórias dentro desse pattern e possíveis formas de tratá-los.

Mas se a ação de compensação também estiver sujeita a falhas?

Podemos usar aqui padrões de resiliência como Retry e Circuit Breaker em um cenário de comunicação síncrona, mais comum no modelo orquestrado.

No cenário de coreografia, pode-se utilizar ferramentas de mensageria que já incorporem certa resiliência como no caso em que ela envie a notificação e não receba o Ack ela mantém a mensagem na fila e tenta reenviar algumas vezes até enviar e receber o ack do Consumer/Subscriber.

Devo sempre realizar um "rollback"?

Uma ação compensatória pode não ser simplesmente voltar para o status que estava antes. Por exemplo: num caso de falha no processamento de uma pagamento de uma compra, o correto seria realizar o estorno do valor pago e não voltar o saldo como era pois pode ter havido outras transações na conta do usuário.

Um outro exemplo emblemático dessa não trivialidade seria uma da etapa do processo ser o envio de e-mail. Se houver falha que interrompa a SAGA em execução, não tem como desfazer esse envio. O correto seria, suponho, enviar outro e-mail de errata.

Devo realmente disparar uma compensação para falha em toda e qualquer transação?

No exemplo utilizado nas ilustrações acima, pode não fazer sentido para o negócio que seu sistema atende já acionar o cancelamento de uma order quando o gateway de pagamento estiver indisponível momentaneamente e, como consequência, impactando a execução da transação dentro do serviço de payment. Isso seria prejudicial já que se perderia uma venda e o cliente impactado talvez não voltasse a comprar em tal e-commerce novamente. O ideal seria ter mecanismos de tratamento e retentativas para ser possível concluir toda a SAGA e garantir a efetivação daquela intenção de compra.

Com isso, podemos afirmar que uma das coisas mais difíceis é pensar em como lidar com as ações compensatórias. É necessário projetar as etapas de sua saga de forma que você sempre consiga dar rollback de uma visão negocial. Inclusive, projete seu sistema de forma que uma vez que você concluiu uma etapa e precisa dar um rollback você não tenha que dar rollback do rollback.

Considerações Finais

Acredito que para uma boa implementação do padrão SAGA, o que manda no final das contas é a regra de negócio da sua aplicação. A arquitetura da sua solução tem que estar totalmente alinhada com as necessidades que seu sistema propõe atender.

Apesar de bastante útil e eficiente em diversos cenários. Talvez essa complexidade de uma SAGA não seja necessária pelo o que diz a regra. Além disso, ele pode não ser tão adequado quando se tem transações fortemente acopladas ou até mesmo dependências cíclicas.

Por fim, espero ter contribuído de alguma forma para o entendimento desse pattern importante para lidar no mundo onde sistemas distribuídos estão cada vez mais presentes no nosso dia a dia. Obrigado pelo tempo dedicado à leitura!

Referências

Distributed Sagas for Microservices

Saga distributed transactions

Pattern: Saga - Chris Richardson

Sagas paper - Hector Garcaa-Molrna and
Kenneth Salem - 1987

Distributed Sagas paper - Caitie McCaffrey - 2015

Um pouco sobre Domain Driven Design

Thiago Henrique — Sun, 13 Jun 2021 00:00:39 +0000

Entender o Domain Driven Design a primeira vista parece ser confuso, principalmente quando você traz consigo alguns PRÉ-conceitos sobre tal tema. A meta desse post é tentar, ainda que de forma geral, visto que o assunto pode ser muito mais complexo do que parece, abrir o caminho para seu entendimento de forma eficiente.

Gostaria de começar dizendo que o DDD não é uma receita para desenvolver softwares em camadas e também não é um padrão arquitetural. O DDD é uma abordagem de modelagem de software que segue um conjunto de práticas com o objetivo de facilitar a implementação de regras complexas ou processos de negócios que tratamos como domínio.

Mesmo não sendo um padrão arquitetural, ele afeta como as decisões arquiteturais são tomadas. O DDD é muito mais sobre a forma de pensar, desenhar e desenvolver aplicações que tem como objetivo implementar o melhor design possível baseado em modelos que refletem a competência da organização.

Essa abordagem tem como precursor Eric Evans, autor do livro “Domain-Driven Design – Atacando as Complexidades no Coração do Software” (o livro azul) publicado em 2003. Evans mostra como um conjunto de best practices de desenvolvimento, boas estratégias de negócio e uma equipe alinhada podem ser benéficos para que um projeto com uma grande complexidade possa ter sucesso.

Outras grandes referências sobre o DDD são as obras de Vaughn Vernon que trazem uma leitura menos densa, usam de uma linguagem mais acessível e demonstram aplicações práticas sobre a abordagem. Ainda estou no processo de leitura, mas acredito que hoje ainda são o que há de mais completo sobre o tema.

Complexidade do Software = Complexidade do domínio x Complexidade técnica acidental

Com um pouco de vivência no processo de desenvolvimento de software é possível perceber que nem tudo sai como o esperado. O entendimento de um negócio é algo dinâmico e que precisa ser um processo contínuo. Dificilmente a primeira versão de uma especificação funcional é a que soluciona adequadamente o problema.

Lá trás, talvez o mais comum seria o arquiteto de software pensar em uma arquitetura robusta e demasiadamente detalhada para atender à necessidade do negócio especialmente quando a especificação é construída. Começando, por exemplo, pela camada de banco de dados, definição de componentes para atender a integrações com serviços externos como envio de e-mail, etc.

Porém o conhecimento do negócio possui necessidades que não conseguimos ver no começo. O projeto cresce. O entendimento do negócio cresce. As necessidades mudam.

As mudanças serão necessárias pois ao decorrer do tempo as necessidades do usuário mudam e uma aplicação criada para tal domínio precisa atendê-las e não as necessidades de meses atrás. Com isso, os desenvolvedores podem encontrar dificuldades em implementar as mudanças dentro de um padrão imposto inicialmente. Isso gera complexidade técnica acidental. O código muitas vezes fica mais complexo do que deveria porque precisa seguir certos padrões imposto anteriormente. À medida que o sistema vai crescendo, a complexidade técnica acidental fica maior do que a própria complexidade do negócio. O resultado disso é o que o DDD chama de Big Ball of Mud. O software fica tão complexo que dar manutenção e evolui-lo se torna uma dor de cabeça.

O DDD entra nessa história justamente para trazer a tona que o entendimento do domínio do negócio é um processo crescente, que necessita da cooperação e comunicação da equipe como um todo. Ao invés do modelo tradicional, em que a comunicação ocorre em apenas algumas etapas do projeto, temos um fluxo de comunicação contínua e colaborativa, por meio de uma única linguagem. O DDD nos instrui a começar mais simples e ir evoluindo a medida que o negócio também evolui.

Domínio

Uma palavra chave no DDD, inclusive já mencionei ela várias vezes até o momento, e importantíssima para que compreendamos suas diretrizes é entender o que representa o domínio.

Poderíamos defini-lo como tudo que compreende o software e faz com que ele funcione. O espaço problema que a equipe está inserida. O principal assunto do seu projeto.

E o processo de modelar o domínio é algo semelhante a um documentário sobre a vida de uma pessoa. Não se registra cada passo, cada acontecimento e detalhe em uma biografia, e sim nos pontos importantes para que a mensagem desejada seja bem compreendida. Da mesma forma, quando falamos em projetos de software, devemos colocar o esforço necessário no que a aplicação precisa para funcionar.

Para fazer uma analogia, podemos lembrar de um jogo bem conhecido, o Banco Imobiliário. Podemos imaginar que ele é um modelo de algo bem mais abrangente e complexo, o mercado imobiliário (domínio).

Design estratégico x Design tático

O DDD nos fornece o design estratégico e design tático como ferramentas para suportar as atividades de modelagem e design do domínio de uma aplicação. E para melhor compreendermos, trago uma definição feita pelo autor Vaughn Vernon:

"Design estratégico é como fazer o rascunho antes de entrar nos detalhes da implementação. Destaca o que é estrategicamente importante para o seu negócio, como dividir o trabalho por importância e como fazer integrações da melhor maneira."

O design estratégico é como esse rascunho, enquanto o design tático é implementação, o detalhamento. O autor ainda diz sobre design estratégico:

“DDD é primariamente sobre modelar uma linguagem ubíqua em contexto delimitado” — Vaughn Vernon

Contexto delimitado é uma barreira semântica onde todos os componentes do modelo terão um significado específico. Já a Linguagem Ubíqua fornece as palavras que existirá nesse contexto. Ubíqua porque ela vai estar implementada no código do software. Entrarei nos detalhes desses itens a seguir.

Os pilares do Design Estratégico

Linguagem Ubíqua

Quando se estuda DDD pode ficar até cansando em falar na linguagem ubíqua. Acontece que ela é essencial para fortalecer os laços entre os especialistas do negócio e o time de desenvolvimento.

Ao aplicá-la, termos estritamente técnicos são substituídos por termos que o usuário compreenda. Essa linguagem universal, como também é conhecida, fica mais próxima da área de negócio do que dos desenvolvedores e ao mesmo tempo que é utilizada entre todos os membros do time (incluindo os Domain Experts), também é implementada como código fonte. É essencial que a Linguagem Ubíqua seja rigorosa e precisa. Uma vez definida, deve ser utilizada até o fim.

Talvez um bom exercício para saber se você está conseguindo utilizar a esse princípio do DDD da maneira correta seria extrair um diagrama de classe e mostrar a um especialista e mostrar para o usuário. Ao fazer isso, ele conseguiria entender e validar o modelo de negócio? Se sim, está próximo do DDD.

Bounded Contexts

Serve para sinalizar até aonde vai a responsabilidade de cada parte do sistema. Cada contexto possui suas responsabilidades claramente definidas (Pagamento, assinatura, frete).
Um ponto importante é que cada contexto pode ter sua própria abordagem de arquitetura (camadas de aplicação, persistência, infraestrutura e etc) inclusive sua própria linguagem ubíqua. Se você trabalha em departamento de vendas, por exemplo, um cliente pode ser alguém que faz ordem de serviço.
Mas para alguém do setor de Marketing pode ser o consumidor de propagandas etc. Isso acontece poque entidades com mesmo nome podem ser encontradas em contexto diferentes.
A utilização de histórias e levantamento do escopo do projeto com o domain expert auxilia no processo de delimitação dos contextos e isso deve ser feito de uma forma mais efetiva possível.

O Vernon Vernon dá uma dica para quando você está em reuniões com pessoas de negócio e elas tem visões diferentes sobre o domínio e precisa-se delimitar os contextos que serão utilizados no projeto. Segundo o autor, quando isso acontece, ou todo mundo tem razão e deve separar os domínios ou a pessoa responsável não está no momento.

Existem algumas referências descrevendo que perguntaram ao Eric Evans se ele pudesse modificar algo no seu livro, o que seria. Ele respondeu que começaria falando primeiro ou focaria mais em Bounded Contexts devido a sua complexidade e importância para a abordagem do DDD.

Em uma fase mais avançada no projeto de uma aplicação, cada Contexto precisa ser transformado em código. Um insight interessante que essa estratégia pode trazer é que normalmente cada contexto definido pode ser transformado em um microsserviço.

Context Maps

O mapa de contexto nada mais é do que um documento, uma imagem, um rascunho anexado na parede, qualquer coisa que facilite o entendimento dos contextos da aplicação.

Pilares do Design Tático

Em linhas gerais iremos falar de padrões de desenvolvimento e estruturação de aplicações cujo domínio é o principal foco. As ferramentas de design tático do DDD se preocupam com os detalhes da implementação. Geralmente trata dos componentes dentro de um contexto delimitado. Ao contrário do design estratégico, espera-se que o design tático
sofra mudanças durante o desenvolvimento do produto

Value Objects

Value Objects é uma coleção de atributos que são imutáveis. Isso significa que normalmente não possuem métodos seters e a entrada dos valores se dá através do construtor. Além disso, possui uma tipagem forte ao invés de dados primitivos. O próprio VO deve conter sua regra de consistência e ele mesmo deve se validar.

Entidade

A principal diferença entre entidade e value object é que entidades possuem identidade. Ou seja, deve ser exclusiva para o objeto mapeado. Nela se encontram as principais lógicas de negócios, mas não fazem persistência. Entidades também possuem estados e comportamentos.

Aggregates

Podemos dizer que Aggregate é uma entidade com características diferentes. Ou ainda, um conjunto de entidades usadas e referenciadas juntas. Quando um dado é alterado essas entidades são tratadas como uma só.
Possui uma raiz de agregação (Aggregation Root) que é a entidade mais "forte" do conjunto e que mantém a integridade do objeto.

Na imagem abaixo, temos exemplos de agregações compostas por sua entidade raiz (azul), demais entidades (cinza) e alguns value objects (branco).

É importante dizer que quando a entidade está isolada, ela é sua própria raiz de agregação.

O Aggregation Root tem entre seus principais objetivos proteger/evitar o acesso direto aos objetos filhos e certificar que o estado desses objetos está sempre consistente.

Outro detalhe que vale mencionar é que deve existir apenas um repositório por agregação.

Na imagem acima, como podemos entender o limite dessas Cliente e Endereço? São entidades distintas ou devem compor uma agregação? Os limites de uma agregação são determinados pela regra de negócio. Então, para entender o limite entre as duas devemos nos perguntar se esse endereço serve pra outra coisa além de pertencer a um cliente. Caso não, deveria compor uma agregação que tem Cliente como raiz.

Repositório

Os repositórios possuem acesso direto a camada de dados. Eles persistem os dados utilizando as entidades. Possui os métodos necessários para consultar, inserir, atualizar e excluir registros de uma fonte de dados.

Serviços de domínio

Os Domain Services trabalham com diversos fluxos de diversas entidades e agregações. Utilizam os repositórios como interface de acesso aos dados, consumem recursos da camada de infra como enviar e-mail, disparar eventos, entre outros. Basicamente fazem tudo o que o model não deve fazer.

Event storming

Apresentados todos esses conceitos é comum olhar tudo isso, entender, mas não conseguir traçar um plano claro sobre como colocá-lo em prática. Para isso existe uma técnica extremamente poderosa para esse fim, o Event Storming.

Se trata de um exercício para criação de modelos de domínios para design estratégico. É basicamente um whorkshop de Brain storming que engaja especialistas do domínio de negócios com desenvolvedores focando mais nos processos de negócio do que em abstrações técnicas (classes, entidades…).

Normalmente se colocam post-its em um quadro para indicar quais eventos de domínio acontecem, a quem interessa, quem provocou, tudo de forma ordenada numa linha de tempo para que se desenhe um caminho que o software irá percorrer. Isso pode clarificar muitas coisas para os membros da equipe.

Essa materialização visual pode ajudar ao desenvolvedor a ter noção do seu papel no contexto do domínio. Acredito que deve ser imprescindível codificar e saber em que ponto você está.

Considerações Finais

Uma provocação válida seria perguntar se vale a pena usar DDD pra tudo? A resposta que eu daria seria: Vale a pena pra quase tudo!

O DDD é voltado para domínios complexos, usá-lo implica em uma efetiva comunicação entre especialistas de negócio e especialistas técnicos, esforço dos devs em programar de forma que o código reflita o domínio. Se um desses pontos não se aplicar ao contexto em questão, provavelmente o DDD não serve para o cenário que você está lidando.

Espero que tenha ficado claro que o DDD não é nenhuma bala de prata, assim como o Clean Architecture que foi tema do meu post anterior, para resolver todos os problemas de um software. O importante é ter em mente que ao identificar que o domínio em questão é complexo, que existe a intenção de desenvolve-lo para que a representação do domínio seja clara até para os Domain Experts e mais, que o cliente está interessado em colaborar com o entendimento do domínio e validação da solução, provavelmente o DDD seja uma boa escolha como abordagem de desenvolvimento.

Tenho ciência que para explanar por completo essa "filosofia" de desenvolvimento de software seria necessário muito mais que esse post. Então espero ter atingido o objetivo de sumarizar os princípios do Domain Driven Design através desse compilado de informações e sirva, por que não, de insumo para discursões construtivas sobre esse tema riquíssimo.

Referências

Domain-Driven Design: uma visão geral — Eriksen Costa

DDD: Boas Práticas na escrita e validação de Entidades de Domínio - Eduardo Pires

Aprenda DDD (Domain Driven Design) do jeito certo - Full Cycle

Course #1 Mastering the art of Microservices Architecture - Alpha Code

Clean Architecture: o que é, vantagens e como utilizar em aplicações na prática

Thiago Henrique — Sat, 12 Jun 2021 22:48:36 +0000

Ultimamente estamos ouvindo falar bastante sobre termos como "Clean Architecture", "Hexagonal Architecture", "SOLID", "DRY", "DDD", etc. Todos eles são princípios, práticas ou abordagens no mundo de desenvolvimento de software que, em essência, convergem para o objetivo de tornar o software mais robusto, escalável e flexível, deixando-o tolerante a mudanças, facilitando a implementação de novos requisitos para a evolução e manutenção do sistema.

Quando se fala em Clean Architecture temos algumas características como:

Arquitetura FOCADA nas regras de negócio: suas regras não devem conhecer o "mundo lá fora" (Frameworks, Ferramentas, Tecnologias, etc).
Inversão de dependências: Por exemplo, seu banco de dados deve depender das suas regras, e não suas regras do seu banco. Sua UI? Mesma coisa!
A melhor decisão é a que você pode tomar depois? Isso não é preguiça, é arquitetura incremental.
Regras de negócio devem ser 100% TESTÁVEIS e INDEPENDENTES!

O diagrama que utilizei na parte superior deste post, segundo Uncle Bob, é uma tentativa de integrar todos esses conceitos e boas práticas arquiteturas em uma única ideia.

Um sistema bem estruturado possui baixo acoplamento e alta coesão, portanto, uma das soluções encontradas é a divisão do sistema em camadas.

Surge então a Regra de Dependência que, acordo com a figura, nos mostra que a seta apenas segue para dentro, ou seja, a camada mais externa visualiza e utiliza a mais interna. O inverso não pode acontecer. Isso não faz com que o software fique dependente ou restritivo, muito pelo contrário, a aplicação dessa regra diminui as limitações do código o tornando organizado e acessível. Não ultrapassar essas barreiras é essencial para otimizar o funcionamento do sistema.

Entities

Na camada de entidades, deve ser alocada a lógica de negócio e as regras de alto nível. Essa camada pode ser usada por todas as outras, tendo em vista que possui regras mais gerais do software, ou seja, as entidades são usadas pelas classes mais externas.

Use Cases

Neste nível do software, cabe a aplicação das regras de negócio para cada caso. Estas são mais específicas e dizem respeito a validações por exemplo.

Interface Adapters

Esta camada tem uma função bem específica como todas as outras. Função esta que é converter as informações vindas das camadas internas (entidades+casos de uso) para o reconhecimento dos elementos pertencentes no próximo nível.

Frameworks and Drivers

Composta pelos elementos mais externos: Frameworks, Banco de dados, bibliotecas e derivações.

Aplicação prática

Para ilustrar como podemos aplicar o conceito de Clean Architecture na prática, trago aqui uma situação onde temos um projeto de API de cadastro utilizando a liguangem NodeJs e algumas bibliotecas como o Express, MongoDB, BCrypt para criptografia de senha e Validator para validar o e-mail recebido.

Sei que esse exemplo é de baixa complexidade, mas acredito que é suficiente para entender a abordagem proposta nesse post.

A imagem abaixo talvez represente a forma como geralmente estruturamos esse tipo de projeto quando não se conhece a abordagem arquitetural que estamos discutindo aqui.

Nesse cenário temos componentes como o SignUpController e SignUpRouter acloplados a biblioteca de terceiros, além de termos componentes que possuem muitas "responsabilidades". Se precisarmos em algum momento trocar o Express por outro framework, será necessário alterar todos os controllers.

Então para dar início a uma transformação na arquitetura do nosso sistema podemos iniciar focando em desacoplar nossos controllers do Express. Esse tipo de decisão em um cenário ideal deveria ser uma tarefa muito fácil. Mas aqui temos que essa biblioteca praticamente "toma conta" do sistema.

O SignUpController aponta para o Express por isso o primeiro passo seria usar o padrão de inversão de dependência (dependency inversion) para fazer com que o Express olhe para nossos controllers.

Para isso, podemos criar um adapter entre os dois que terá a tarefa de converter as interfaces do controller para a realidade do Express. Uma das particularidades do Express é que ele espera receber o (req, res) como parâmetros nas rotas definidas.

Também não podemos permitir que o adapter dependa diretamente do SignUpController. Devemos fazer com que ele possa adaptar qualquer controlador, assim, criamos uma camada Presentation e dentro dela uma interface Controller, que irá servir como um limite desta camada para fazer a inversão de dependência. O adapter precisa de qualquer classe que utilize a interface.
Com isso a dependência inverteu. Se eu precisar trocar, só altero o adapter.

Seguindo em frente, precisamos agora desacoplar a biblioteca para validar e-mail para que nosso presentation layer não dependa de um componente externo. Criamos um EmailValidatorAdapter semelhante ao adapter criado anteriormente.
Assim, em vez de o SignUpController depender diretamente desse adapter, definimos, ainda na camada de apresentação, uma nova interface EmailValidator que diz o que esse componente deve fazer e "alguém" de fora implementa a interface definida. Dessa forma desacoplamos e se outros controladores precisarem usar esse validador poderemos facilmente reutilizar o componente. Ainda temos o benefício de, se um dia optarmos por substituir essa biblioteca por uma regex por exemplo, alteraremos apenas um componente.

Podemos dizer que é nossa camada Utils que é mais genérica irá conter coisas que podem ser utilizadas em qualquer lugar.

Surge, então, a necessidade de uma camada de negócio que diga o que precisamos fazer. Pois para realizar um cadastro, precisamos salvar os dados no banco de dados, mas antes disso, queremos criptografar a senha do usuário.
Criamos então uma interface AddAccount que nada mais é do que a representação de uma camada de negócio da aplicação, a camada Domain. Essa camada não terá implementação, mas apenas protocolos que dizem o que nossa regra de negócio deve fazer.
Com isso, o SignUpController irá precisar de alguém que implemente essa interface para criar uma conta de usuário. Não importa se a implementação será com banco de dados, cache, ou dados "mockados", o que importa é que a implementação respeite a interface definida.

Assumindo que queremos a implementação da regra de negócio voltada para armazenamento em banco de dados, criaremos a Data layer que terá o componente DbAddAcccount.
Esse sim irá utilizar o BCrypt para fazer a criptografia da senha do usuário. Mas não queremos acoplá-los diretamente. Assim como antes, criaremos o BCryptAdapter para isolar os nossos componentes do BCrypt que uma biblioteca externa.
Ele ficará dentro da Infra layer, camada que terá implementações de interface voltadas para frameworks. E agora para realizar a inversão de dependência, criamos a interface Encrypter ainda na Data layer já que o DbAddAcccount precisa de alguém que saiba fazer criptografia e não ele mesmo saber como faz.
Com isso a dependência inverteu novamente. O Infra layer que aponta para o Data layer e não o Data layer apontando para o Infra.

Para finalizar temos o a dependência com o MongoDb. Criaremos o componente AddAccountMongoRepository que sabe usar o mongo e criaremos também a interface AddUserRepo pois outros componentes podem precisar de "alguém" que saiba inserir no banco de dados, não importa qual.
Inversão de dependência feita mais uma vez.

Com isso as bibliotecas de terceiros estão cada vez mais isoladas, cada vez mais na camada mais "fora" da nossa arquitetura. Se futuramente quisermos trocar MongoDB, vamos alterar apenas um componente.

Realizamos até aqui transformações, com a ajuda do padrão de projeto Adapter, que removem o acoplamento entre as camadas. Mas para conseguir ter uma solução completa e desacoplar nossas camadas precisamos acoplar uma delas, e esta será a Main layer.

Ela será responsável por criar instâncias de todos os objetos. Exemplo: Para criar a rota de signup precisamos do SignUpController, que por sua vez precisa de alguém que implemente a interface AddAccount. Mas que sua implementação não será instanciada no controller.
"Alguém" irá criar essa instância e injetará no controller. O Main layer fará a composição desses objetos através de outro design pattern, o Composite, e toda composição será feita em um lugar só.

Abaixo está o desenho final desse exemplo, destacando com cores para melhor visualização das camadas. Acredito que tenhamos chegado bem próximo de um desenho arquitetural bem estruturado com baixo acoplamento e alta coesão. Observa-se que as dependências externas estão sempre nas "pontas" e facilmente podemos troca-las sem afetar o resto do sistema.

Considerações Finais

As ideias propostas por Uncle Bob, padronizam o desenvolvimento de software moderno.
Nota-se que os métodos sugeridos, se aplicados de maneira correta, organizam o código, facilita o trabalho em equipe, e entre outros benefícios. Isso não quer dizer que o Clean Architecture é uma "bala de prata" para desenvolver softwares. Ressalto aqui que sua aplicação deve ser avaliada de acordo com o tipo de projeto e suas particularidades.

Referências

Artigo do Uncle Bob sobre Clean Architecture.

Curso NodeJs, Typescript, TDD, Clean Architecture e SOLID na Udemy do Rodrigo Manguinho.