DEV Community: Kauê Gatto

O teorema CAP não é a ferramenta ideal para você! (E pra ninguém)

Kauê Gatto — Fri, 25 Apr 2025 21:10:48 +0000

Contexto

Esse texto não tem como propósito apresentar o teorema CAP de maneira aprofundada, e sim promover reflexões e um olhar crítico usando artigos, teoremas e textos feitos levando em consideração a aplicação do teorema no mundo real.

Boa parte deste texto na real é baseada no paper A Critique of the CAP Theorem - de Martin Kleppmann, autor também do livro DDIA. Se este artigo te interessar, recomendo a leitura do material original, mais denso e aprofundado em aspectos científicos.

Para textos que explicam o conceito do CAP, recomendo o incrível artigo do Matheus Fidelis

Conceito Original

O CAP é um teorema apresentado para classificar sistemas de banco de dados distribuídos, e foi apresentado originalmente na forma "Consistência, DIsponibilidade (Availability) ou Tolerância à Partições, escolha dois." - Significando que você pode ter CA (Consistência e Disponibilidade), CP (Consistência e Tolerância à Partições) ou AP (Disponibilidade e Tolerância à Partições), mas nunca os três. Esse conceito normalmente é representado por meio de um diagrama de Venn

Debates futuros concluíram que essa formulação não é das melhores, principalmente porquê é difícil distinguir entre CA e CP. Se seu sistema não é resistente à partições de rede, como você pode chamar ele de altamente disponível? Mas, se ele é resistente, ele não pode ser classificado como disponível?

Ambiguidades

Hoje em dia, muitos autores preferem formular o CAP da seguinte forma: Se não existe partição de rede, um sistema pode ser Consistente e Disponível. Se existe partição de rede, você tem que escolher entre disponibilidade (AP) ou consistência (CP).

Alguns autores definem um sistema CP como um sistema onde a maior parte dos nós de um lado de uma partição irão continuar operando normalmente, e um sistema CA como um sistema que pode falhar catastróficamente quando ocorrer uma partição de rede. Essas definições não são necessariamente "concordadas", é contraintuitivo chamar um sistema de "disponível", de maneira categórica, se ele pode falhar de maneira catastrófica sob uma partição de rede, enquanto um sistema que continua funcionando é chamado de "indisponível".

Outro ponto apresentado pelo autor é que chamar um sistema de maneira categórica de "Disponível" ou "Indisponível" não necessariamente tem muito sentido, visto que disponibilidade é algo a ser observado, uma métrica, e nenhum sistema será 100% disponível ou indisponível.

Desta forma, alguns textos 2 defendem que você não deve deixar a resistência à partições de rede de lado, portanto o CA torna-se inviável em termos realistas.

Tradeoff entre latência e consistência

O Ponto do teorema CAP são os tradeoffs que você deve levar em consideração ao escrever e utilizar software, dependendo da maneira a qual ele deve se comportar. Martin Kleppmann abrange isso de outra forma, em minha opinião, mais simples de entender que o modelo original e melhor formalizada.

O teorema CAP é simplista demais e mal compreendido demais para ser útil na caracterização de sistemas. Portanto, peço que retiremos todas as referências ao teorema CAP, paremos de falar sobre ele e o deixemos de lado. Em vez disso, deveríamos usar uma terminologia mais precisa para raciocinar sobre nossas compensações. - Martin Kleppman, em seu blog, no post # Por favor, pare de chamar os bancos de dados de CP ou AP

Se há um delay (latência) de rede, você deve esperar pelo menos pelo tempo do delay d para realizar alguma operação (escrita ou leitura) em um software, esse conceito faz sentido porquê seria impossível escrever e ler antes da rede em si, a menos que você tenha memória compartilhada (atualizada só na leitura, ou só na escrita) ou a menos que tenha uma baixa consistência (casual consistency). Note que aqui, já estamos falando de modelos de consistência de dados, esse é um fator essencial para entender o modelo a seguir.

Um novo Modelo: Sensível à Latência

Um ponto importante é considerar que o CAP (Como teorema) não leva em conta fatores importantes ao escrever e avaliar software para o mundo real. Se você responde uma chamada em 10 horas por conta de um problema no seu banco de dados, pode classificá-lo como disponível? Quais são os SLA's que devemos levar em consideração para discutir essas terminologias?

Aqui, o foco principal do modelo proposto por Kleppmann é a latência. Aplicada ao mundo real.

To find a replacement for CAP with a latency-centric viewpoint we need to examine how operation latency is affected by network latency at different levels of consistency.

Na hora de classificarmos modelos, usaremos uma notação similar ao Big(O), só que ao invés de ser o tamanho do Input, descrevemos a latência de uma operação como uma função de uma latência de rede.

A notação big O para latência operacional ignora fatores constantes, como o número de round-trips que um algorítmo realiza, mas captura a essência do que precisamos saber para construir sistemas que podem tolerar falhas de rede: O que acontece quando a latência da rede piora drásticamente

Um exemplo apresentado no artigo, mostra, diferentes níveis de consistência e como cada um deles é afetado por uma latência (d)

Note que isso não significa que você precisa, para todo banco de dados que for buscar, procurar qual estratégia de consistência e replicação entre bancos é utilizada (embora é isso que eu ache), mas deve, ao menos, saber como ele é afetado pela latência, escolhendo a chave correta para cada parafuso. Apesar disso, recomendo a leitura do paper - Replicated Data Consistency Explained Through Baseball

Outro ponto importante aqui com o modelo sensível à latência é pararmos de classificarmos sistemas como CP ou AP de maneira simplista 4:

Dentro de um software, você pode ter diferentes operações com características diferentes de consistência.*
Dentro de um software, definir consistência pode ser complicado
- O Apache Zookeper, utiliza, para lidar com replicação, o algorítmo de Consenso, que opta por consistência em prol da disponibilidade.
- Apesar disso, o Zookeeper faz com que cada cliente se conecte em um nó, e cada leitura bata nesse nó, portanto, mesmo que hajam escritas mais atualizadas em outro nó, você não as verá
Podem existir sistemas que não se enquadram nas características definidas no CAP, e fazem total sentido para seu caso de uso. Portanto, o modelo sensível à latência é mais um - entenda as possibilidades do seu sistema e pense por você mesmo. O ponto é que chamar um sistema de não consistente por não ser linearizável não é o caminho

O modelo de sensibilidade à latência tem como objetivo enfatizar como diferentes níveis de consistência são impactados pela latência, portanto, o seu conhecimento advindo do teorema CAP não estava totalmente incorreto. Quanto mais latência, mais complicado fica de se manter a consistência, e você começa a sacrificar características importantes de seu modelo, como a capacidade de responder mais rapidamente em certos cenários, e até mesmo responder, como um todo, em outros.

Extra:

A partir de agora, entramos mais no lado científico da coisa.

Incongruências do CAP

O Teorema foi formalizado por Gilbert e Lynch [25, 26].
O primeiro teorema do cap é:

It is impossible in the asynchronous network model to implement a read/write data object that guarantees the following properties:
• Availability
• Atomic consistency
in all fair executions (including those in which messages are lost

O problema é que a formalização de Disponibilidade por parte dos autores é:
"For a distributed system to be continuously available, every request received by a non-failing node in the system must result in a response"

Portanto, se todos os nós de um sistema distribuídos estão com problema, ele está automaticamente Disponível pela definição do CAP. Essas e outras incongruências convergiram para a criação de um novo modelo, fácil de se entender e mais correto, mas que abrangesse as mesmas ideias do CAP.

Existem bem mais listadas no artigo original.

Terminologia Proposta

Availability

Is an empirical metric, not a property of an algorithm. It is defined as the percentage of successful requests (returning a non-error response within a predefined latency bound) over some period of system operation.

Delay-sensitive

describes algorithms or operations that need to wait for network communication to complete, i.e. which have latency proportional to network delay. The opposite is delay-independent. Systems must specify the nature of the sensitivity (e.g. an operation may be sensitive to intra-datacenter delay but independent of inter-datacenter delay). A fully delay-independent system supports disconnected (offline) operation.

Network faults

encompass packet loss (both transient and long-lasting) and unusually large packet delay. Network partitions are just one particular type of network fault; in most cases, systems should plan for all kinds of network fault, and not only partitions. As long as lost packets or failed requests are retried, they can be modeled as large network delay.

Fault tolerance

is used in preference to high availability or partition tolerance. The maximum fault that can be tolerated must be specified (e.g. “the algorithm can tolerate up to a minority of replicas crashing or disconnecting”), and the description must also state what happens if more faults occur than the system can tolerate (e.g. all requests return an error, or a consistency property is violated).

Consistency

refers to a spectrum of different consistency models (including linearizability and causal consistency), not one particular consistency model. When a particular consistency model such as linearizability is intended, it is referred to by its usual name. The term strong consistency is vague, and may refer to linearizability, sequential consistency or one-copy serializability.

Bibliografia

[0] - https://fidelissauro.dev/teorema-cap/
[1] - Kleppman, Martin. A Critique of the CAP Theorem. https://arxiv.org/pdf/1509.05393
[2] - https://codahale.com/you-cant-sacrifice-partition-tolerance/
[3] - Terry, Doug. Replicated Data Consistency Explained Through Baseball https://www.microsoft.com/en-us/research/wp-content/uploads/2011/10/ConsistencyAndBaseballReport.pdf
[4] - https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html

Arquiteturas Orientadas à Eventos, Microserviços e Monolitos Modulares

Kauê Gatto — Sat, 15 Feb 2025 19:33:50 +0000

Esse post surgiu de uma experiências que estou obtendo ao desenvolver um sistema monolítico modular com golang e arquitetura orientada à eventos.

https://github.com/kauegatto/modular-ecommerce

Visite meu blog, onde posto os textos finalizados (tem mais conteúdo lá):

kaue.cat

Arquitetura Orientada à Eventos, Microserviços e Monolitos

Se você é desenvolvedor, é provável que já tenha ouvido falar sobre alguns conceitos comuns: SOLID, Acoplamento, Coesão, etc. Ao trabalhar com sistemas, conhecemos vantagens e desafios de diferentes tipos de arquiteturas à nível de software e solução, e entendemos como esses conceitos impactam a experiência, tempo e qualidade de um software.

Desde a última década, Microserviços se tornaram um desses conceitos fundamentais, e suas vantagens e desvantagens começaram a ser mais palpáveis conforme a adoção desse tipo de arquitetura em sistemas reais. Sistemas distribuídos orientados à serviços são frequentemente vendidos como a solução ideal para todos os sistemas, enquanto isso, outros autores argumentam exatamente o contrário.

Sam Newmann, em seu livro "Construindo Microserviços":

"Infelizmente as pessoas passaram a ver os sistemas monolíticos como algo a ser evitado, isto é, algo que é inerentemente problemático. Uma arquitetura monolítica é uma opção, e uma opção válida. Eu poderia ir além e dizer que, em minha opinião, é a opção padrão sensata como estilo de arquitetura.
Em outras palavras, estou procurando um motivo para ser convencido a utilizar microserviços, em vez de procurar um motivo para não usar"

No mesmo livro, outras arquiteturas são apresentadas, dentre elas o "Sistema Monolítico Modular":

"Para muitas empresas, o sistema monolítico modular pode ser uma excelente opção. Se as fronteiras dos módulos forem bem definidas, é possível ter um grau elevado de paralelismo nos trabalhos, ao mesmo tempo que os problemas da arquitetura de microserviços, mais distribuída, são evitados, pois há uma topologia muito mais simples para implantação. A Shopify é um ótimo exemplo de uma empresa que empregou essa técnica como uma alternativa à decomposição em microserviços e parece fnucionar muito bem para essa empresa"

E então:

"Um sistema distribuído é um sistema no qual a falha de um computador que você nem sabia que existia pode deixar seu prório computador inutilizável" - Leslie Lampert

Um ponto que favorece bastante monolitos modularizados é a fácil capacidade de transformar módulos em serviços independentes (Microserviços), conforme a necessidade passe a existir. Aproveitando o baixo acoplamento entre os módulos, essa alteração se torna mais simples pois evita mexer em outras partes do sistema (No máximo nos adaptadores, responsáveis por se comunicar com esse novo serviço), visto que módulos agem como uma camada de isolamento.

De maneira geral, tendo a pensar que para organizações menores, prova de conceitos ou outros casos de uso, microserviços podem não ser o ideal para você, apesar disso, o foco do artigo é menos nesses dois tipos de arquitetura, e sim como ambos podem se beneficiar (ou não) de um sistema de comunicação assí baseado em eventos.

Independente se você está produzindo seu software em uma arquitetura realmente distribuída ou só modularizada, um ponto importante é garantir o baixo acomplamento e alta coesão desses módulos ou serviços.

Protegendo seu código de acoplamento ruim

Acoplamento sempre existirá, livros como "OOP e Solid para Ninjas" - de Mauricio Aniche e "Desbravando SOLID" - de Alexandre Aquiles enfatizam isso, mas principalmente, a diferença entre um acoplamento bom e ruim.

De maneira geral, acoplamento está intrinsecamente relacionado à coesão. Módulos com pouco acoplamento ruim são coesos, se elementos de código mudam em conjunto, eles devem se manter em conjunto, assim, quando algum desses elementos mudar, isso não exige alteração em múltiplas partes de seu sistema de uma vez, o que seria um forte indicativo que a coesão do seu sistema não é das melhores.

Um exemplo: Regras de negócio de compras devem se manter no módulo e contexto de compras, se esse módulo começar a fazer suposições e uso de partes que não pertencem a esse módulo, isso com certeza não é um acoplamento tão bom. Agora suponha que você está fazendo um código que com certeza não tem perspectivas de mudar de ORM, criar camadas de abstração talvez seja um trabalho desnecessário, que pode inclusive poluir sua base de código.

Ao desenhar e modelar um Sistema Modular, queremos sempre que os módulos possuam baixo acoplamento entre si. Como isso fica no código? Uma forma interessante é, sempre que possível, expor contratos entre diferentes módulos, evitando uma comunicação direta. Outra maneira de evitar acoplamento é evitar que um módulo acesse recursos como banco de dados de outro sob responsabilidade de outro módulo - isso é frequentemente chamado de database-per-service- isso provavelmente traria para o módulo consumidor preocupações sobre tratamento de dados que deveriam estar no módulo que é o responsável pelo banco.

Modelos de Comunicação Síncronos e Assíncronos

Aqui, entraremos em um debate sobre padrões de comunicação síncronos e assíncronos.
Recomendo a leitura de dois excelentes posts do Matheus Fidelis que se aprofundam bem mais no tema:

Se tratando de Sistemas Modulares (sejam eles Microserviços ou não), um fator principal a ser levado em consideração é o acoplamento entre sistemas. A maneira com que eles se comunicam é um alto contribuínte nessa "métrica":

De maneira geral, podemos dividir a comunicação em duas grandes categorias:

Padrão síncrono - Request/response
A chamada é feita por um cliente à um servidor, que eventualmente response a chamada pela mesma conexão, que se mantém aberta até a resposta acontecer.
Note que aqui, o protocolo de comunicação é síncrono, mesmo que você crie alguma thread para processar esse tipo de mensagem de forma assíncrona, de maneira não bloqueante, isso não torna seu protocolo assíncrono, apenas seu processamento.
Padrão de Comunicação Assíncrono
A conexão entre quem pede a mensagem e o servidor não fica aberta esperando pela resposta em um tempo específico. Em algum momento, o servidor notifica o processamento da informação, normalmente o servidor faz a chamada proativa de chamar seus clientes via webhook ou simplesmente publica mensagens ou eventos sem se preocupar com quem e quando essa notificação será processada.
1. Baseado em Mensagens - Aqui, sabemos qual nosso destinatário, normalmente enviamos comandos para outros serviços, como por exemplo: Atualize o Pedido x. (Figura 1). Existe uma variação assíncrona do modelo Request/Response comummente chamada de request-reply, onde a comunicação entre cliente/servidor se dá por meio de filas.
2. Baseado em Eventos - Aqui, sua aplicação notifica eventos, coisas que aconteceram sob seu domínio. Se um pedido é pago, o serviço de pagamentos é responsável por enviar um evento de "Pagamento Concluído", para que quem necessitar dessa informação, use-a. Aqui, a aplicação que propaga eventos não sabe quem irá consumi-los. (Figura 2)
  1. Costumamos chamar esses eventos de "Eventos de Integração", pois se comunica com um "Bounded Context" diferente.
  2. Eventos normalmente são publicados em um sistema apartado, conhecido como Event Bus. Kafka é capaz de realizar a tarefa que um event bus realiza, RabbitMQ é um event bus, NATS.io também.

*Figura 1. Extraído de .NET Microservices: Architecture for Containerized .NET Applications

Figura 2. Extraído de .NET Microservices: Architecture for Containerized .NET Applications

Sincronismo Vs Assíncronismo

[❗] NOTA
Ao usar event bus externo com um monolito, fazer chamadas de rede é algo que deve ser evitado.

O Caminho Síncrono

Uma abordagem popular é implementar microsserviços baseados em HTTP (REST), devido à sua simplicidade. Uma abordagem baseada em HTTP é perfeitamente aceitável; a questão aqui está relacionada a como você a utiliza. Se você usa requisições e respostas HTTP apenas para interagir com seus microsserviços a partir de aplicações cliente ou de API Gateways, tudo bem. Mas se você criar longas cadeias de chamadas HTTP síncronas entre microsserviços, comunicando-se através de suas fronteiras como se os microsserviços fossem objetos em uma aplicação monolítica, sua aplicação eventualmente terá problemas.
.NET Microservices: Architecture for Containerized .NET Applications pg.35

O problema aqui se dá principalmente pela cadeia de serviços, se você se comunica de maneira síncrona com um serviço, ele provavelmente pode se comunicar de maneira síncrona com outro, em uma cadeia que pode ser infinita. Caso um desses sistemas falhe (e eventualmente vão falhar), você terá um problema.

Na verdade, se seus microsserviços internos estão se comunicando criando cadeias de requisições HTTP como descrito, pode-se argumentar que você tem uma aplicação monolítica, mas baseada em HTTP entre processos em vez de mecanismos de comunicação intra-processo.
.NET Microservices: Architecture for Containerized .NET Applications pg.35

Apesar disso, note que programar um serviço síncrono provê código muito mais simples de ser seguido pelo fluxo de execução natural, mais simples de ser desenvolvido, mas provavelmente menos resiliente. Caso queira forçar resiliência em padrões síncronos, com retries com backoff exponencial, circuit breakers, você acaba perdendo o que na minha opinião é a maior vantagem desse tipo de comunicação, a simplicidade.

O Caminho Assíncrono

Um código orientado à eventos possui uma boa quantidade de desafios associados - Consistência Eventual, Duplicação de mensagens, configuração de um serviço externo, mas oferece mais resiliência de forma que processos assíncronos podem ser feitos em algum momento no futuro, podendo deixar seu sistema parcialmente operante em casos de falha de alguns módulos. Note que isso aqui nos remete fortemente ao teorema CAP, onde temos que escolher entre Consistência e Disponibilidade. Não temos como manter nossa aplicação consistente se algum de nossos serviços caiu e precisamos nos comunicar com ele naquele momento.

Em um sistema de e-commerce, você não quer que sua aplicação deixe de receber pedidos porquê o adquirente que está integrado caiu, ou porquê seu módulo de processamento está bugado, ao deixar esses eventos / pedidos guardados para reprocessamento no futuro, você evita qualquer perda financeira.

Esse texto, como uma explicação para decisões e desafios acerca de um projeto pessoal, reflete minha decisão: Nesse projeto, fui com a arquitetura orientada à eventos principalmente por questões de aprendizado.

Conceitos Importantes de uma comunicação assíncrona

Consistência Eventual

Revisitando o exemplo anterior do E-commerce, onde você não quer deixar de registrar pedidos:
Supondo que você registre os pedidos, mas por algum tipo de falha, não consiga enviar esse pedido para o Event Bus, isso significa que outras aplicações não receberão essa notificação que o pedido foi feito, o mesmo pode acontecer para qualquer domínio. Esse tipo de atraso na atualização de alguns dados é chamado de consistência eventual, o seu sistema, eventualmente, se tornará consistente. É importante avisar ao usuário como a consistência eventual pode o impactar, resultando que pedidos pagos não mostrem na hora, que dados salvos em seu perfil não apareçam imediatamente, etc.

[❗] NOTA
Em alguns lugares, é capaz que o termo ["Consistência Posterior"](https://pt.wikipedia.org/wiki/Consist%C3%AAncia_posterior) seja empregado, pela semântica da palavra "Eventual" no português, que está mais próximo do "Ocasionalmente". Quando falamos de consistência "eventual", o sistema irá ficar consistente em algum momento no futuro.

Entregas de Mensagens

Sistemas que tratam envio de mensagens trabalham com diferentes tipos de garantia (que podem, ou não, ser configurados)

At Least Once

Em sistemas que garantem entrega "At Least Once", toda mensagem será entregue pelo menos uma vez ao consumidor. Isso significa que, em casos de falha ou timeout, o sistema pode reenviar a mesma mensagem, resultando em possíveis duplicatas. Esse modelo é especialmente útil quando perder uma mensagem é inaceitável - por exemplo, em sistemas de pagamento onde perder uma transação seria catastrófico.
Em um sistema que tenta automaticamente se recuperar de falhas, a mesma mensagem poderia ser enviada múltiplas vezes. Graças à falhas de hardware e rede, o receptor deve ser capaz de implementar uma operação de processamento dessas mensagens que seja idempotente.

At Most Once

Na garantia "At Most Once", o sistema garante que uma mensagem será entregue no máximo uma vez. Se houver falha na entrega, a mensagem será perdida ao invés de ser reenviada. Esse modelo é útil em cenários onde duplicatas são mais problemáticas que perdas - como em sistemas de métricas ou logs, onde perder algumas mensagens é aceitável, mas duplicatas poderiam distorcer análises.

DEDUP (Deduplicação)

A deduplicação é uma estratégia fundamental, especialmente quando se usa "At Least Once". Deduplicação é exatamente o que seu nome implica, removendo mensagens duplicadas de uma lista.
Existem várias formas de implementar deduplicação, como identificadores únicos para uma mesma mensagem. Note que dedup garante Idempotência, onde diferentes requisições ou eventos com o mesmo conteúdo têm o mesmo resultado. Frequentemente sistemas garantem à você at-least-once, e ter idempotência é uma obrigatoriedade!
A maior parte dos Event Buses possuem jeitos de lidar com a deduplicação de mensagens, mas também podemos fazer isso no código de destino do seu Microserviço (como verificar um messageId, ou se for um evento de pedido pago, o OrderId, visto que um pedido não pode ser pago mais de uma vez), talvez ter as validações em ambas as pontas seja a melhor opção.

Outros Problemas

Outros problemas que podem surgir ao lidar com sistemas assícronos são:

Ordenação de mensagens, happens-before. Vídeo sobre o assunto.
Transações distribuidas. Artigo sobre o assunto # Garantindo a Publicação de Eventos e Consistência
Ao publicar em um Event Bus, diversos problemas podem acontecer: Partições de rede, indisponibilidade do bus, queda do seu módulo. Todos esses cenários podem resultar na perda de mensagens.
Outro problema é a alteração no estado interno de um objeto de domínio dentro do seu bounded context ser notificada de maneira errônea

E se nossa mensagem nem for enviada?

Outro ponto importante e frequente, que decidi dar um pouco mais de prioridade é: E se nossa mensagem nem for enviada ao event bus? e se ele cair?

Existem alguns padrões e técnicas que nos permitem lidar com esse tipo de situação, uma delas é o Outbox, onde temos uma tabela em algum armazenamento persistente (normalmente um banco de dados) responsável por informar que um evento está pendente de ser enviado:
Fazemos a alteração da nossa entidade de domínio em uma transação junto com a inserção do evento como "pendente". Caso dê errado, nem nosso objeto nem o evento ficam inconsistentes

Caso essa transação seja concluída, temos essa tabela, avisando que o evento deve ocorrer, e um outro serviço (normalmente chamado de worker) processará ele em caso de falhas, reenviando o evento.

Note que com essa abordagem, você persiste apenas os eventos de integração de origem de cada microserviço. Outras abordagens (Como Event Sourcing - Que não irei abordar aqui), podem necessitar que você armazene mais eventos.

Exemplo real

if (catalogItem == null) return NotFound();
bool raiseProductPriceChangedEvent = false;
IntegrationEvent priceChangedEvent = null;

if (catalogItem.Price != productToUpdate.Price)
    raiseProductPriceChangedEvent = true;
if (raiseProductPriceChangedEvent) // Create event if price has changed
{
    var oldPrice = catalogItem.Price;
    priceChangedEvent = new ProductPriceChangedIntegrationEvent(catalogItem.Id,
    productToUpdate.Price,
    oldPrice);
}
// Update current product
catalogItem = productToUpdate;
// Just save the updated product if the Product's Price hasn't changed.
if (!raiseProductPriceChangedEvent)
{
    await _catalogContext.SaveChangesAsync();
}
else // Publish to event bus only if product price changed
{
    // Achieving atomicity between original DB and the IntegrationEventLog
    // with a local transaction
    using (var transaction = _catalogContext.Database.BeginTransaction())
    {
        _catalogContext.CatalogItems.Update(catalogItem);
        await _catalogContext.SaveChangesAsync();
        await _integrationEventLogService.SaveEventAsync(priceChangedEvent);
        transaction.Commit();
    }
    // Publish the integration event through the event bus
    _eventBus.Publish(priceChangedEvent);
    _integrationEventLogService.MarkEventAsPublishedAsync(
    priceChangedEvent);
    }
return Ok();
}

Ou seja:

Se o Banco cair?
1. Se essa operação for uma reação à um evento, a mensagem não será processada, para que possa ser processada em um momento futuro. Mantemos consistência e faremos o que for necessário, assim que possível.
2. Se for fruto de uma chamada síncrona, podemos retornar um erro. De qualquer forma, o sistema não fica inconsistente.
Se não conseguirmos publicar no event bus?
1. Será publicado depois, teremos um log de que o evento está pronto para a publicação, nosso domínio interno estará atualizado, mas os outros não. Como trabalhamos com consistência eventual, é um cenário completamente ok!
2. Se o banco cair na hora de salvarmos como enviado, enviaremos o evento novamente, por isso a importância da idempotência

Esse tipo de cenário enfatiza como a alta resiliência de uma aplicação pode ser alcançada com mais facilidade usando um padrão de comunicação assíncrono por meio de eventos e mensagens

Conclusão

A função deste texto é dar introdução à arquiteturas síncronas, assíncronas e orientadas à eventos, mostrando vantagens, desafios e técnicas comuns. Os posts posteriores darão mais ênfase na arquitetura à nivel dos módulos - Como desenhar os bounded contexts, quanto de informação colocar nos eventos de integração, etc.

Espero que tenham gostado!

Referências

Construindo Microserviços - Sam newman
OOP e SOLID para ninjas
Desbravando SOLID
EVENT STORMING - DOMAIN DRIVEN DESIGN, EVENT SOURCING E CQRS! - YouTube
Message Driven Architecture to DECOUPLE a Monolith - YouTube
Long live the Monolith! Monolithic Architecture != Big Ball of Mud - YouTube
# .NET Microservices: Architecture for Containerized .NET Applications
https://newsletter.simpleaws.dev/p/distributed-transactions-event-driven-architectures
Mensageria, Eventos, Streaming e Arquitetura Assincrona
Padrões de Comunicação Síncronos

1. Concorrência Java: Threads! Processando em Paralelo e Ganhando Throughput

Kauê Gatto — Fri, 31 May 2024 03:00:00 +0000

Seja bem vindo, esse daqui é o primeiro de 6 posts sobre concorrência em

Contexto

Threads são unidades de execução dentro de um processo. Um processo é um programa em execução que contém pelo menos uma thread. As threads permitem que um programa execute várias tarefas ao mesmo tempo (ou pelo menos aparentemente).

Vantagens de programar com múltiplas threads:

Uma das principais razões para usar múltiplas threads é melhorar o desempenho de um programa. Tarefas pesadas e demoradas podem ser divididas em threads separadas, permitindo que diferentes partes do programa sejam executadas em paralelo. Isso pode levar a uma utilização mais eficiente dos recursos da CPU e, consequentemente, a um tempo de resposta mais rápido.

![[Untitled 109.png|Untitled 109.png]]
No entanto, programar com threads também traz desafios, como a necessidade de lidar com concorrência (quando várias threads tentam acessar ou modificar os mesmos recursos ao mesmo tempo) e a possibilidade de erros difíceis de depurar (como as condições de corrida), pois os resultados de um mesmo código não serão necessariamente os mesmos (não determinísticos).

O multithreading ajuda ou não?

1. Operações de I/O:
Quando um programa precisa realizar operações de entrada/saída -- I/O (e elas são o gargalo), como leitura/gravação de arquivos, comunicação com bancos de dados ou solicitações de rede, há frequentemente momentos em que a CPU fica ociosa, esperando que os dados sejam lidos ou escritos.
Nessa situação, se uma nova thread tomasse conta da situação, ela não seria mais executada pelo processador enquanto estivesse ociosa, pois aconteceria o que chamamos de troca de contexto, que é basicamente fazer com que outra thread seja processada. Isso permite que outras threads que necessitem de processamento real tenham suas operações executadas pelos núcleos da CPU, ou até mesmo lançar (ou usar) mais threads para já lançar outras chamadas que também exigem esse tempo de espera, conhecidas como bloqueantes. Isso ajuda a aproveitar melhor o tempo da CPU, melhorando a eficiência geral do programa.
Imagine um contexto onde você precisa ler dois arquivos .txt, essa operação poderia ser realizada paralelamente se lançássemos duas threads, uma para ler cada arquivo, sendo cada uma processada em um núcleo, diminuindo o tempo de execução essencialmente pela metade

2. Código CPU-bound:
Quando o programa está executando tarefas intensivas em CPU, como cálculos matemáticos complexos, simulações ou processamento de imagem, uma única thread pode não ser capaz de aproveitar totalmente a capacidade de processamento da CPU. Dividir essas tarefas em threads separadas permite que múltiplos núcleos da CPU trabalhem em paralelo, acelerando o processamento.
Nesse caso, devemos tomar cuidado, pois a quantidade de tarefas que pode ser paralelizada realmente é igual a quantidade de núcleos do seu processador (lógicos + físicos).

![[Pasted image 20240404211738.png]]
A imagem acima representa a troca de contexto, note que esse processo não é necessariamente instantâneo e resulta em possível perda de cache, o que pode ser agressor à performance - Fonte.

A frequência de trocas de contexto tem impacto na eficiência do sistema operacional: quanto menor o número de trocas de contexto e menor a duração de cada troca, mais tempo sobrará para a execução das tarefas em si. Assim, é possível definir uma medida de eficiência E do uso do processador, em função das durações médias do quantum de tempo t e da troca de contexto c.

Java: Threads!

O Objeto Thread

O objeto java.lang.Thread é um wrapper em cima das threads do sistema operacional

[!important]
Note que as Threads são objetos wrappers em torno das threads do SO, portanto, se essas threads do S.O são pesadas (e são), as Threads em Java também são.

Em Java, podemos trabalhar com threads de algumas maneiras, a primeira que veremos é com a classe Thread, essas classes precisam dar o override do método run:

class ThreadExample extends Thread{
  char c;
  public ThreadExample(char c) {
    this.c = c;
  }

  @Override
  public void run() {
    System.out.printf("\nComeçouuu!: %s\n", c);
    for (int i = 0; i < 100 ; i++) {
      System.out.print(c);
    }
  }
}

public static void main(String[] args) {
    /* Todo programa em execução é "feito" de threads, esse não é uma exceção*/
    Thread.currentThread().getName();
    ThreadExample t1 = new ThreadExample('A');
    ThreadExample t2 = new ThreadExample('B');
    ThreadExample t3 = new ThreadExample('C');
    t1.run();
    t2.run();
    t3.run();
  }

![[Untitled 110.png|Untitled 110.png]]

Pronto! (Só que não) → Note que os objetos thread ainda estão rodando na mesma thread, nesse caso, usar Thread.run() executa o método run, nao inicia a thread, nesse caso, devemos rodar start()!

public class Thread01 {
  public static void main(String[] args) {
    /* Todo programa em execução é "feito" de threads, esse não é uma exceção*/
    Thread.currentThread().getName();
    ThreadExample t1 = new ThreadExample('A');
    ThreadExample t2 = new ThreadExample('B');
    ThreadExample t3 = new ThreadExample('C');
    t1.start();
    t2.start();
    t3.start();
  }
}

![[Untitled 1 70.png|Untitled 1 70.png]]

[!question] Reflexão
Criar um objeto do tipo thread faz sentido? Você está especializando uma thread realmente? A herança faz sentido nesse caso? [[2. SOLID]]

1. Interface Runnable

Nesse caso, acho válido começar diferente, vamos ler uma parte da javadoc da classe runnable

0. Javadoc

The Runnable interface should be implemented by any class whose instances are intended to be executed by a thread. The class must define a method of no arguments called run.

In addition, Runnable provides the means for a class to be active while not subclassing Thread. A class that implements Runnable can run without subclassing Thread by instantiating a Thread instance and passing itself in as the target.
In most cases, the Runnable interface should be used if you are only planning to override the run() method and no other Thread methods. This is important because classes should not be subclassed unless the programmer intends on modifying or enhancing the fundamental behavior of the class.

A documentação do JAVA responde perfeitamente a reflexão anterior, se você discorda, pode seguir em frente, mas particularmente acho que é um argumento difícil de rebater.

Exemplo:

class ThreadRunnable implements Runnable {
  char c;

  public ThreadRunnable(char c) {
    this.c = c;
  }

  @Override
  public void run() {
    System.out.printf("\nComeçouuu!: %s\n", c);
    for (int i = 0; i < 100; i++) {
      System.out.print(c);
    }
  }
}

public class Thread01 {
  public static void main(String[] args) {
    /* Todo programa em execução é "feito" de threads, esse não é uma exceção*/
    Thread.currentThread().getName();

    var t1Runnable = new ThreadRunnable('a');
    var t2Runnable = new ThreadRunnable('b');
    var t3Runnable = new ThreadRunnable('c');
    Thread t1 = new Thread(t1Runnable);
    Thread t2 = new Thread(t2Runnable);
    Thread t3 = new Thread(t3Runnable);
    t1.start();
    t2.start();
    t3.start();
  }
}

![[Untitled 2 56.png|Untitled 2 56.png]]

Estados de uma thread

![[Untitled 3 42.png|Untitled 3 42.png]]
É interessante sabermos disso, pois podemos dar dicas para o S.O como dizer para que uma thread running pare, ou notificando que uma thread se tornou Runnable.

Melhorando o Código

Se não precisarmos de construtor! podemos usar uma lambda, pois Runnable é uma @FunctionalInterface:

Thread t1 = new Thread( () -> {/*codigo*/});

Ou, um pouco mais verboso:

Runnable simplerRunnable = () -> {
      System.out.printf("\nComeçouuu!: %s\n", c);
      for (int i = 0; i < 100; i++) {
        System.out.print(c);
      }
};

Prioridade

Prioridades podem ser atribuídas à threads, conforme mostra o código:

Thread t3 = new Thread(t3Runnable,"nomeC");
t3.setPriority(Thread.MAX_PRIORITY);

![[Untitled 111.png|Untitled 111.png]]

[!important]
Note que prioridades são indicações do que você deseja para o scheduler, uma thread de prioridade 1 pode rodar andar da prioridade 10, você não deve desenvolver um código baseado em prioridade

Sleep

Imagine que você deseja que uma thread ocorra sem fim, mas rode a cada 2 minutos, como pode fazer isso? 🤔

Uma das maneiras é usar um Thread.sleep(milis) e pedir para que a thread pare por algum tempo, note que é importante esse código estar dentro de um try-catch, por sua possibilidade de gerar uma exceção (caso a thread seja interrompida, por exemplo)

@Override
  public void run() {
    System.out.printf("\nComeçouuu!: %s\n", c);
    for (int i = 0; i < 100; i++) {
      System.out.print(c);
    }
    try {
      Thread.sleep(1000);
    } catch (InterruptedException e) {
      throw new RuntimeException(e);
    }
  }

![[Untitled 1 71.png|Untitled 1 71.png]]

Yield

Yield serve para indicarmos / darmos uma dica para o scheduler do JVM faça a thread voltar para Runnable (pare) por um tempo. [[2. Começando com o Código]]

![[Untitled 2 57.png|Untitled 2 57.png]]
O yield é um dos principais elementos que permitem a existência de Virtual Threads.

Join

![[Untitled 3 43.png|Untitled 3 43.png]]
Join serve para avisarmos a thread main que ela deve esperar para continuar seu fluxo q uando as operações terminarem
Quando você chama o método join em uma determinada (thread), você está essencialmente dizendo: "Pera ai, só continua quando essa tarefa terminar". Isso é útil quando você tem partes do programa que precisam estar totalmente prontas antes que outras partes possam prosseguir.
Um exemplo seria um cenário onde você precisa comparar 3 pesquisas de viagem de avião para conseguir ver o preço mais barato, você pode dar o join nas 3 threads que rodaram essa operação de I/O (a ordem não irá importar, pois estaremos limitados pela última de qualquer jeito) e então depois comparamos os resultados

Resumidamnete, o join é especialmente útil quando você precisa garantir a ordem correta das operações ou quando precisa coletar resultados de várias threads antes de prosseguir.

// t1 roda antes de t1 e t2
Thread t1 = new Thread(new ThreadRunnableYieldJoin('A'));
Thread t2 = new Thread(new ThreadRunnableYieldJoin('B'));
Thread t3 = new Thread(new ThreadRunnableYieldJoin('C'));

t1.start();
try {
  t1.join();
} catch (InterruptedException e) {
  throw new RuntimeException(e);
}
var threads = List.of(t2,t3);
threads.forEach(Thread::start);

public static void main(String[] args) {
// t1 e t2 em paralelo
    Thread t1 = new Thread(new ThreadRunnableYieldJoin('A'));
    Thread t2 = new Thread(new ThreadRunnableYieldJoin('B'));
    Thread t3 = new Thread(new ThreadRunnableYieldJoin('C'));

    t1.start();
    t2.start();

    try {
      t1.join();
      t2.join();
    } catch (InterruptedException e) {
      throw new RuntimeException(e);
    }

    t3.start();
  }
}

Referências

[!info] Qual a finalidade do Transient e Volatile no Java?
As vezes quando vou declarar meus atributos noto o transient e o volatile.
https://pt.stackoverflow.com/a/116080

[!info] Maratona Java Virado no Jiraya
Melhor, maior, e o mais completo curso de Java em português grátis de toda Internet está de volta.
https://www.youtube.com/playlist?list=PL62G310vn6nFIsOCC0H-C2infYgwm8SWW>)

O que são microserviços? Para que servem e quando usar?

Kauê Gatto — Wed, 08 May 2024 01:13:21 +0000

Disclaimer:

Esse artigo é baseado totalmente no Livro Building Microservices, do Sam Newman!

Visão Geral

Microserviços são partes independentes entre si que são modeladas em torno de uma regra de negócio. Um serviço encapsula uma funcionalidade e permite que ela seja acessível por uma rede através de requisições REST.

Microserviços são um tipo de arquiteturas orientadas a serviço, onde fronteiras entre serviços devem ser traçadas, mas apesar disso o release independente é chave.

Do lado de fora, um microserviço é uma caixa preta, exceto por seus endpoints expostos.

[❗] Importante
Como o ideal é que a implementação interna do microserviço seja alheia ao mundo exterior, cada microserviço idealmente deve se importar apenas com sua linguagem de programação, com seu banco de dados e outros detalhes internos de implementação. Não necessariamente isso será a verdade em um mundo real, nesses casos, precisamos nos preocupar principalmente com acessos concorrentes. Locks distribuídos podem ser uma tacada boa para lidar com recursos compartilhados entre múltiplos serviços

Como microserviços se baseiam muito na ocultação de informação, expondo somente o necessário através de interfaces externas, permitem uma maior visão no que pode ou não mudar facilmente. O código interno de um microserviço pode mudar a vontade desde que as interfaces externas não mudem seu comportamento.

Pontos-Chave sobre microserviços!

Deploy Independente

Essa é a ideia que conseguimos mudar um microserviço e dar deploy nele sem termos que fazer deploy em qualquer outro microserviço, na realidade, é o jeito que devemos tratar os microserviços, não somente o que podemos fazer.

Para isso acontecer, devemos ter certeza que nossos microserviços estão pouco acoplados . Isso significa que o contrato entre os serviços devem ser explícitos e estáveis. Algumas escolhas de implementação podem tornar isso inviável, como por exemplo o compartilhamento de banco de dados.

Modelados ao redor de um domínio do negócio

Microserviços são modelados ao redor de seu domínio, para resolver um problema em específico. Isso ajuda bastante na separação e no entendimento do domínio.

Donos de seu próprio estado

Microserviços devem ter dentro de si todos os seus dados importantes, por isso o tópico anterior é importante na hora de delimitar as funções de um microserviço. Um microserviço deve ser capaz de conversar com outro para pedir a ele alguma informação que não possui, isso deve acontecer via a interface externa desse outro microserviço, o que garante o deploy independente desses serviços

Flexibilidade

Microserviços te compram opções, no sentido que elas tem um preço. Mais microserviços, na via de regra, te oferecem mais flexibilidade, contudo, também são mais difíceis de manusear. O tamanho dos microserviços não é algo tão importante quanto a pergunta de quantos microserviços você consegue administrar e de que forma você faz isso sem que eles sejam uma bagunça acoplada.

Maneira de trabalho com microserviços

Tecnologias são importantes, mas cuidado

Normalmente é mais produtivo ir incluindo novas tecnologias que dão suporte à microserviços conforme seu sistema cresça e mais serviços apareçam, contudo, algumas ferramentas são essenciais, como por exemplo um agregador de log, ou outras ferramentas que são capazes de visualizar traces entre multiplo serviços, detectar gargalos, etc.

Containers e Kubernetes

Idealmente, cada microserviço deve ser rodado isoladamente, garantindo que um problema em um microserviço não possa afetar outro, por isso, containers são a maneira mais viável de se utilizar os microserviços.

Depois de implementar os microserviços. provavelmente será dificícil de administrá-los, por isso, é ideal a utilização de ferramentas que servem para a orquestração desses containers, kubernetes é a ferramenta mais conhecida para tal.

Streaming

Embora microserviços sejam uma maneira de migrar de bases de dados monolíticas, ainda precisamos encontrar maneiras de transferir informações entre microserviços, ao mesmo tempo que organizações buscam cada vez mais feedbacks em tempo real. Existem muitas ferramentas que ajudam em tal cenário, o apache kafka e rabbitMQ são ferramentas comuns para isso.

Vantagens de microserviços

Tecnologias Heterogêneas

Com um sistema composto por diversas partes que conseguem trabalhar isoladamente e apenas externalizar uma interface, conseguimos programar essas partes com tecnologias totalmente diferentes, desde que o contrato entre os serviços sejam mantidos. Isso nos permite escolher a ferramenta correta para cada serviço.

Robustez

Microserviços são capazes de lidar com falhas em determinados setores específicos sem com que toda a aplicação morra ( o que usualmente acontece em monolitos ). Com os microserviços implementados corretamente, conseguimos lidar com uma falha total em um serviço e apenas fazer com que uma parte do sistema não funcione perfeitamente. Se o sistema de busca da netflix falhar, você ainda é capaz de assistir filmes, criar contas, realizar pagamentos e afins.

Scaling

Uma arquitetura baseada em microserviços possibilita o “scaling” de coisas isoladamente, onde podemos dedicar mais hardware a partes que realmente necessitam daquilo, e sistemas mais fracos a grupos de serviços menos utilizados.

O autor dá um exemplo do marketplace multimilionário focado em modas “Gilt’, e diz que essa foi a principal razão para a Gilt aderir aos microserviços, o mesmo diz que a empresa hoje possui mais de 450 microserviços.

Facilidade no Deploy

Uma alteração em uma linha de código em um sistema monolito normalmente pede que o sistema todo passe por um deploy novamente, contudo, graças a característica de deploys independentes, isso não acontece com os microserviços

Alinhamento organizacional

Essa questão é óbvia para times grandes de desenvolvimento, separar equipes em partes específicas que trabalham com produtos que podem ser melhorados sem necessitar grande movimentações de outras equipes desde que o contrato pré estabelecido continue sendo respeitado é maravilhoso.

Composição

Microserviços podem ser usados em diferentes ambientes e usados em conjuntos para obtermos resultados específicos, ajudam no reúso de código e na eficiência.

Pontos de Dor / Fraquezas

[📋 Citação]
We’ll be covering many of these issues in depth throughout the rest of the book—in fact, I’d argue that the bulk of this book is about dealing with the pain, suffering, and horror of owning a microservice architecture.” - Autor do Livro Building Microservices, usado como base.

Experiência do Desenvolvedor.

Quando você vai incluindo mais serviços, cria-se uma situação mais complexa para rodar os serviços em máquinas locais, 5/6/7 serviços baseados em JVM podem rodar, mas quando chegamos nas dezenas, a situação é mais trabalhosa, inclusive com runtimes que são menos taxativos que a JVM.

Outro ponto importante é que mudanças em charts, terraform, vulnerabilidades que devem ser aplicadas em múltiplos serviços podem ser uma dor de se administrar.

Sobrecarga de tecnologias

Não é porque microserviços te dão a opção de rodar diferentes tecnologias, bancos, linguagens que você deve fazê-lo, são possibilidades, não requisitos.

Além disso, diversas empresas, equipes ou desenvolvedores individuais desenvolvem um amor por novas tecnologias que às vezes não valem a pena, que servirão apenas para incluir mais complexidade em um escopo definido.

Report de Dados

Report de dados com microserviços são mais complicados, principalmente pelo fato de termos (idealmente) banco de dados quebrados em diferentes partes, onde uma simples operação de join não resolve as coisas de uma vez.

Segurança, Monitoramento, Testes

São basicamente a mesma coisa, temos diversos microserviços conversando entre si, vários fluxos a serem monitorados, os testes e2e ficam muito difíceis. Esses assuntos vao ser tratados com mais detalhes depois.

Consistência de dados

Respeitar a consistência de dados em um sistema muito mais distribuído, com muitos processos independentes, que muitas vezes cuidam de uma base de dados única é difícil. Transações distribuídas existem mas costumam ser problemáticas, o ideal é utilizarmos tecnologias como sagas.

Onde é complicado usar?

Empresas que possuem times excessivamente pequenos
Empresas que não conseguem arcar com os custos iniciais de colocar diversas máquinas na cloud rodando serviços
Empresas as quais o produto não está pensado, está muito sucetível a mudanças
- Vai lascar bastante com os boundaries

Microservices need to talk to each other through n/w packets. Monolith is mostly IPC and hence faster.
Monitoring all the Microservices (100s) and checking their health to ensure smooth running is a pain.
Monolith need not worry about consistency since they primarily operate on the same data store.
Monolith in general have better latency since the non-determinism of microservices is not present

Onde eles funcionam bem?

Empresas com diversos desenvolvedores
- Permite que um dev ou um time não entre no caminho do outro;
Empresas que possuem um aporte inicial bom de dinheiro
Software que precisa da possibilidade de escalar, e idealmente para diversas regiões do mundo
Softwares que precisam de flexibilidade.

Virtual Threads em Java - O Java que voa!

Kauê Gatto — Mon, 01 Apr 2024 20:24:01 +0000

Opa, só passando para avisar que esse post veio originalmente do meu blog, se puderem dar uma força lá, vai ser muito bom :)
https://www.kaue.cat/posts/virtual-threads/

Outro aviso é que o post está em progresso, acho que está bom o suficiente para ser lançado, mas vocês provavelmente vão encontrar alguns problemas, mas um conteúdo bem rico!

O Artigo

Primeiro, vamos estabelecer objetivos desse artigo:

✅ Objetivos

Dar uma breve Introdução à Programação Concorrente e Paralela
Explicar o histórico da programação concorrente no JAVA
Mostrar brevemente como o problema de throughput era resolvido no JAVA
Explicar Virtual Threads
Mostrar exemplos práticos do uso de Virtual Threads
Mostrar concorrência estruturada

E...

❌ Não Objetivos

Não é objetivo explicar em detalhes mecanismos de programação concorrente & paralela, para isso, recomendo fortemente esse artigo do Matheus Fidelis
Não é objetivo explicar em detalhes como a programação reativa e multithreaded é feita em JAVA (sem ser com Virtual Threads)
Entrar em detalhe sobre assuntos específicos do pacote java.util.concurrent - Futures, Executors, Synchronizers, Coleções Thread-Safe, etc. Para isso, recomendo ocurso gratuito de Java do DevDojo

Virtual Threads

Virtual Threads é uma feature que está disponível para uso em um LTS desde o Java 21, também chamado de project loom, é o projeto de integrar maneiras mais fáceis de escrever programas concorrentes e reativos em JAVA, a fim de misturar performance e usabilidade

🔑 Pontos Chave

A virtual thread is a Thread — in code, at runtime, in the debugger and in the profiler.

A virtual thread is not a wrapper around an OS thread, but a Java entity.

Creating a virtual thread is cheap — have millions, and don’t pool them!

Blocking a virtual thread is cheap — be synchronous!

No language changes are needed.

Pluggable schedulers offer the flexibility of asynchronous programming.

✅ Objetivos

Enable server applications written in the simple thread-per-request style to scale with near-optimal hardware utilization.

Enable existing code that uses the java.lang.Thread API to adopt virtual threads with minimal change.

Enable easy troubleshooting, debugging, and profiling of virtual threads with existing JDK tools.

❌ Não Objetivos

It is not a goal to remove the traditional implementation of threads, or to silently migrate existing applications to use virtual threads.

It is not a goal to change the basic concurrency model of Java.

It is not a goal to offer a new data parallelism construct in either the Java language or the Java libraries. The Stream API remains the preferred way to process large data sets in parallel.

Conceitos

De maneira geral, usamos as virtual threads por um motivo: Aumentar o throughput (vazão) da nossa aplicação (não velocidade, que está relacionado à latência. Por enquanto, a maneira mais comum é uma: Programação Reativa, vamos entender como a programação reativa era no passado, e como vamos implementá-la com as virtual threads.

💡 Throughput?

Throughput diz respeito à quantidade de elementos que você processa por uma medida de tempo (exemplo: Requests/Segundo em uma aplicação HTTP, Mensagens Processadas por Segundo em um message broker).

Programação Assíncrona e Concorrente

A maior parte do código que escrevemos é síncrono, isso significa que o código vai ser executado imediatamente quando chegar naquela instrução, o código assíncrono é um código que vai ser executado, em algum momento no futuro, como uma promessa de execução.
Códigos assíncronos não significam a mesma coisa que concorrentes, um forEach assínrono, por exemplo, roda na thread principal de um programa, um código concorrente significa que ele vai ser executado em outra thread!

Podemos criar tarefas (Tasks) para rodarem em Threads, e para criarmos uma Thread, temos duas maneiras:

Criar uma Thread a partir de seu construtor, e passar à ela sua Task
Usar uma pool (piscina) de Threads e deixar com que o executor entregue a tarefa à uma thread disponível (se ela existir)
1. Essa Abordagem é muito comum pois Threads são recursos limitados que não são leves de criar e destruir
2. Conexões de Banco de dados também passam ficam em um "Pool" quando usamos frameworks como o Spring, a biblioteca que cuida da criação de um Pool de Conexões é o Hikari

Nesse cenário, vamos criar uma task, submetê-la ao Executor, e receberemos uma promessa de execução, por esse ponto de vista, essa tarefa é assíncrona pois será executada no futuro, mas também é concorrente, pois será executada em uma thread diferente. Aqui os conceitos se encontram, mas não são a mesma coisa código concorrente é assíncrono, mas nem todo código assíncrono é concorrente!

Execução Bloqueante

Uma execução bloqueante significa que uma instrução está sendo executada pela sua CPU (ou por um core dela) e que nenhuma outra instrução irá ocorrer enquanto a anterior ainda estiver acontecendo, mesmo que sua CPU não esteja sendo utilizada, normalmente em uma espera de I/O ou para entrar em um bloco de código sincronizado.
Nesse cenário irá ocorrer uma troca de contexto, um processo relativamente "caro" para sua CPU que basicamente desaloca o processo até que ele exija algo novamente da CPU, por sua vez, o código não bloqueante garante que sua CPU evite trocas de contextos e esteja sempre sendo utilizada.

O Cenário Atual - Por quê usar Virtual Threads?

Primeiro, analise o código JAVA que faz uma chamada HTTP padrão para um servidor:

URI url = URI.create("https://mydata.com/data");
HttpClient client = HttpClient.newBuilder().build();
HttpRequest request = HttpRequest.newBuilder(url).GET().build();
var response = client.send(request, HttpResponse.BodyHandlers.ofString());

Aqui, podemos ver que nossa CPU só é realmente utilizada de maneira eficiente durante 200 nano segundos, e fica ociosa a maior parte do tempo, esperando a resposta da chamada.

Como podemos arrumar isso?

0. O Patinho lento - One Request Per Thread

A primeira ideia é irmos no aspecto concorrente, quando sua thread estiver esperando, o Task Scheduler vai remover ela do núcleo que está rodando (Context Switching) e coloca outra thread no lugar, executar uma request em cada thread (One-Request-Per-Thread) é a maneira convencional, que vêm sido utilizada há bons anos.

Nesse cenário, precisaríamos de 500 mil de threads - advindo da proporção entre tempo ocioso e trabalhado. 100ms/200ns - (requests) nesse núcleo para alcançarmos o uso de 100% de CPU, garantindo que sua CPU não fique ociosa. Isso definitivamente não boa bom, né?
As threads no JAVA encapsula uma thread do Sistema Operacional, também chamada de Platform Thread ou Kernel Thread, o problema é que o custo de criação de criação de uma Thread em JAVA, é o mesmo de criar uma Thread no SO, que é relativamente caro

Fonte

Recursos caros como threads são colocados em "Pools" para lidar com eles de maneiras mais eficientes:

❝ ❞

Developers sometimes use thread pools to limit concurrent access to limited resources. For example, if a service cannot handle more than 20 concurrent requests then making all requests to the service via tasks submitted to a thread pool of size 20 will ensure that. This idiom has become ubiquitous because the high cost of platform threads has made thread pools ubiquitous
Fonte: https://openjdk.org/jeps/444

Perfeito, mas voltando ao exemplo anterior, precisamos de 500.000 threads, quanto isso vai nos custar?

Memória: 500.000Mb
Tempo de início: 500 Segundos

Com isso, entendemos que o modelo One Request Per Thread não é mais viável:
O artigo Transformation patterns for a reactive application, de Bruno Miguel Mendonça Maia pontua como característica desses sistemas :

Pontos Negativos

( – ) Concurrency. Synchronous programming is not the best suited model for dealing with concurrency as the execution will start and block the current thread while waiting for the result.
( – ) Throughput. While a thread waits for the expensive execution to return its result, the OS can exchange active threads to promote concurrency, but this has overhead costs and hinders throughput due to thread context switching and cache invalidation.
( – ) Latency. Thread blocking on execution and the lower throughput due to the OS exchanging active threads and consequently cache invalidation leads to poorer latency.

Pontos Positivos

(+) Ease of use. The synchronous sequential model and its typical imperative programming style provides a familiar thinking model that results in ease of use.
(+) Maintainability. Synchronous programming and its sequential execution model provides an easy to reason with concept that in turn increase maintainability. Furthermore, error handling in sequential execution is easier to tackle.

1. O patinho feio - Processar múltiplos requests em uma Thread

Essa abordagem é a abordagem Reativa. A abordagem reativa tem um princípio simples de dividir uma request em pequenas porções e nenhuma porção pode conter código bloqueantes:

Aqui dividimos as etapas como foi acordado anteriormente (exceto pelo fato de que a step2 pode bloquear a CPU)
Com isso, precisamos usar um framework reativo que permita que usemos essas lambdas (aqui o exemplo é completableFuture, que faz a mesma coisa, mas usando a pool de threads, mas serve bem para explicar.):

Seu framework de execução terá a responsabilidade de conectar as lambdas para que o resultado delas seja passado para a próxima função corretamente, é seu trabalho não escrever código bloqueante nesse caso. Como seu framework vai ter pouquíssimas threads (talvez só uma por núcleo), e muitas requests vão ser processadas em uma mesma thread, escrever código bloqueante vai impactar MUITO sua performance.

Nesse caso em específico, a thread não será bloqueada pois CompletableFuture conhece o HttpRequest.send() e registra um callback, que será executado quando a função terminar de rodar.

Pontos Negativos

Código difícil de ler
Código difícil de dar manutenção
É fácil de arruinar a performance com um pedaço de código bloqueante.
Difícil de testar

2. O Patinho que Existe - Futures e Callback Hell

Aqui, usamos ainda do One Request Per Thread, mas com estratégias um pouco diferentes, usamos Futures para escrever código paralelizável e concorrente, ganhando performance.

Fonte https://blog.soaresdev.com/funcoes-callback-em-javascript/

O post Virtual threads: Are futures a thing of the past?, na Java Magazine, retrata a história do código concorrente em Java. Lá, é retratado o uso de Futures para colocar suas Threads para rodar porções bloqueantes em paralelo:

void handleRequest(Socket socket) {
  var request = new Request(socket);
  var futureWeather = CompletableFuture.supplyAsync(() -> Weather.fetch(request), exec2);
  var futureRestaurants = CompletableFuture.supplyAsync(() -> Restaurants.fetch(request), exec2);
  var futureTheaters = CompletableFuture.supplyAsync(() -> Theaters.fetch(request), exec2);

  new Page(request)
      .setWeather(futureWeather.join())
      .setRestaurants(futureRestaurants.join())
      .setTheaters(futureTheaters.join())
      .send();
}

A ordem em que as três tasks esperam pelo resultado não importa, a thread coloca os 3 Jobs para rodar, e depois bloqueia (espera) até que elas tenham terminado. Mas pera, "e depois bloqueia (espera) até que elas tenham terminado"... Exato, ainda podemos melhorar isso bastante, bloquear Threads tem um custo:

Esse blocking traz a possibilidade de deadlocks acontecerem. Aqui, teremos uma pool para computar recursos e para lidar com requests.
Bloquear e desbloquear threads traz perda de performance. Claramente sua CPU não vai ficar 2 Segundos esperando a sua resposta de I/O e vai colocar outra thread para trabalhar nesse meio termo, apesar disso, existe um custo não só para fazer a troca de contexto, mas isso também irá causar perda de dados em cache no processador, resultando em cache misses quando a thread estiver de volta.

Podemos "resolver" isso usando callbacks!

public class Server {
  private final ServerSocket server = new ServerSocket(port);
  private final ExecutorService exec = Executors.newFixedThreadPool(16);

  public void run() {
    while (!server.isClosed()) {
      var socket = server.accept();
      exec.execute(() -> handleRequest(socket));
    }
    exec.close();
  }

  void handleRequest(Socket socket) {
    var request = new Request(socket);

    var futureWeather = CompletableFuture.supplyAsync(() -> Weather.fetch(request), exec);
    var futureRestaurants = CompletableFuture.supplyAsync(() -> Restaurants.fetch(request), exec);
    var futureTheaters = CompletableFuture.supplyAsync(() -> Theaters.fetch(request), exec);

    var page = new Page(request);

    futureWeather.thenAccept(weather ->
        futureRestaurants.thenAccept(restaurants ->
            futureTheaters.thenAccept(theaters ->
                page.setWeather(weather)
                    .setRestaurants(restaurants)
                    .setTheaters(theaters)
                    .send())));
  }
}

Future.thenAccept recebe como argumento um consumer, que irá consumir o resultado dessa future, a invocação de thenAccept só registra o código para uma execução futura, ele não espera o código ser completado, registrando um callback.
Nesse cenário, as threads nunca são bloqueadas e uma única pool não muito vasta pode ser usada. O código também está livre de deadlocks.

Callbacks são difíceis de escrever e de debugar, você pode ter percebido que nesse simples evento, já temos 3 níveis de aninhamento de código, podemos melhorar isso usando outras features para lidar com futures de maneira não bloqueantes, como usando thenCombine:

void handleRequest(Socket socket) {
  var request = new Request(socket);

  var futureWeather = CompletableFuture.supplyAsync(() -> Weather.fetch(request), exec);
  var futureRestaurants = CompletableFuture.supplyAsync(() -> Restaurants.fetch(request), exec);
  var futureTheaters = CompletableFuture.supplyAsync(() -> Theaters.fetch(request), exec);

  CompletableFuture.completedFuture(new Page(request))
      .thenCombine(futureWeather, Page::setWeather)
      .thenCombine(futureRestaurants, Page::setRestaurants)
      .thenCombine(futureTheaters, Page::setTheaters)
      .thenAccept(Page::send);
}

Nesse cenário, o único processamento que a thread que lida com as conexões performa é a criação da página base, mas isso também poderia ser assíncrono:

public class Server {
  private final ServerSocket server = new ServerSocket(port);
  private final ExecutorService exec = Executors.newFixedThreadPool(16);

  public void run() {
    while (!server.isClosed()) {
      var socket = server.accept();
      handleRequest(socket);
    }
    exec.close();
  }

  void handleRequest(Socket socket) {
    var futureRequest = CompletableFuture.supplyAsync(() -> new Request(socket), exec);

    var futureWeather = futureRequest.thenApplyAsync(Weather::fetch, exec);
    var futureRestaurants = futureRequest.thenApplyAsync(Restaurants::fetch, exec);
    var futureTheaters = futureRequest.thenApplyAsync(Theaters::fetch, exec);

    futureRequest
        .thenApplyAsync(Page::new, exec)
        .thenCombine(futureWeather, Page::setWeather)
        .thenCombine(futureRestaurants, Page::setRestaurants)
        .thenCombine(futureTheaters, Page::setTheaters)
        .thenAccept(Page::send);
  }
}

3. O Patinho bonito - Construir uma thread virtual, mais leve que Platform Threads.

As virtual threads são exatamente isso, conseguimos performance, simplicidade e boa capacidade de manutenção evitando códigos reativos e sem ter medo de códigos bloqueantes.

❝ ❞ Implicações

Virtual threads are cheap and plentiful, and thus should never be pooled: A new virtual thread should be created for every application task. Most virtual threads will thus be short-lived and have shallow call stacks, performing as little as a single HTTP client call or a single JDBC query. Platform threads, by contrast, are heavyweight and expensive, and thus often must be pooled. They tend to be long-lived, have deep call stacks, and be shared among many tasks.
In summary, virtual threads preserve the reliable thread-per-request style that is harmonious with the design of the Java Platform while utilizing the available hardware optimally. Using virtual threads does not require learning new concepts, though it may require unlearning habits developed to cope with today's high cost of threads.
Virtual threads will not only help application developers — they will also help framework designers provide easy-to-use APIs that are compatible with the platform's design without compromising on scalability.

❗ Reforçando!

Não crie pools de threads virtuais!

Escrevendo Virtual Threads

As maneiras que podemos criar virtual são simples:

Via factory

Thread t3 = Thread.ofVirtual()  
        .name("Thread virtual!")  
        .start(task);  
t3.join();

Thread.startVirtualThread(task)

Thread t4 = Thread.startVirtualThread(task);  
t4.join();

Usando um executorService (com o método newVirtualThreadPerTaskExecutor):

public static void execute(){  
    var set = ConcurrentHashMap.<String>newKeySet();  

    Runnable task = () -> set.add(Thread.currentThread().toString());  

    int N_TASKS = 500;  

    try (var executorService = Executors.newVirtualThreadPerTaskExecutor()) {  
        for (int index = 0; index < N_TASKS; index++) {  
            executorService.submit(task);  
        }  
    }  

    System.out.println("# threads used = " + set.size());  
}

Como Virtual Threads funcionam

Uma virtual thread é executada em cima de uma platform thread, que chamamos de Carrier Thread. Essas carrier threads são organizadas em uma única ForkJoinPool, onde cada Platform (também carrier) terá uma waitlist de virtual threads associadas à ela.

Para evitar Starvation das threads do Sistema Operacional, se uma waitlist de uma Platform Thread zerar, ela vai "roubar" tarefas de outras threads.
Com isso, percebemos que executar um "runnable" em uma virtual thread, na realidade roda ele em uma thread real, portanto, se formos executar uma operação completamente não bloqueante, virtual threads são mais caras, é um overhead, se for o caso, rode-as diretamente na thread comum. Virtual Threads são feitas para executar códigos bloqueantes!

⚠️ Aviso

Virtual Threads não são feitas para rodar operações em memória!

Quando operações bloqueantes rodam em virtual threads, elas se separam de sua Carrier Thread, usando "yield" para basicamente suspender a execução desse código, liberando a thread principal para trabalhar com outras coisas, então essa virtual thread é guardada na memória principal (heap) e quando estiver pronta, é colocada de novo na waitlist das threads principais, através de um callback, mas isso tudo é feito de maneira transparente!

Note que Continuation.yield() responsável por garantir esse processo para que a thread principal não seja bloqueada, precisa ser implementado em operações bloqueantes (isso já está feito).

Por exemplo, nessa linha de código:

response.send(future1.get() + future2.get());

Essas operações vão fazer com que a thread virutal monte e desmonte de sua carrier thread diversas vezes, provavelmente uma para cada call para get()e possívelmente muitas outras vezes ao longo da execução de .send() graças às operações de I/O.

Exemplos

Exemplo usando um executor que cria uma virtual thread para cada task bloqueante.

void handle(Request request, Response response) {
    var url1 = ...
    var url2 = ...

    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
        var future1 = executor.submit(() -> fetchURL(url1));
        var future2 = executor.submit(() -> fetchURL(url2));
        response.send(future1.get() + future2.get());
    } catch (ExecutionException | InterruptedException e) {
        response.fail(e);
    }
}

String fetchURL(URL url) throws IOException {
    try (var in = url.openStream()) {
        return new String(in.readAllBytes(), StandardCharsets.UTF_8);
    }
}

Mesmo procedimento usado no capítulo [[#2. O Patinho que Existe - Futures e Callback Hell]], mas usando virtual threads, que não bloqueiam sua CPU!

void handleRequest(Socket socket) {
  var request = new Request(socket);

  var futureWeather = new CompletableFuture<Weather>();
  var futureRestaurants = new CompletableFuture<Restaurants>();
  var futureTheaters = new CompletableFuture<Theaters>();

  Thread.startVirtualThread(() -> futureWeather.complete(Weather.fetch(request)));
  Thread.startVirtualThread(() -> futureRestaurants.complete(Restaurants.fetch(request)));
  Thread.startVirtualThread(() -> futureTheaters.complete(Theaters.fetch(request)));

  new Page(request)
      .setWeather(futureWeather.join())
      .setRestaurants(futureRestaurants.join())
      .setTheaters(futureTheaters.join())
      .send();
}

Parecido com o exemplo 2, mas com um aroma mais funcional (Considerando que o executorService provê virtual threads.)

void handleRequest(Socket socket) {
  var futureRequest = CompletableFuture.supplyAsync(() -> new Request(socket), exec);

  var futureWeather = futureRequest.thenApplyAsync(Weather::fetch, exec);
  var futureRestaurants = futureRequest.thenApplyAsync(Restaurants::fetch, exec);
  var futureTheaters = futureRequest.thenApplyAsync(Theaters::fetch, exec);

  futureRequest
      .thenApplyAsync(Page::new, exec)
      .thenCombine(futureWeather, Page::setWeather)
      .thenCombine(futureRestaurants, Page::setRestaurants)
      .thenCombine(futureTheaters, Page::setTheaters)
      .thenAccept(Page::send);
  }
}

Uma maneira imperativa, sem o uso de futures

void handleRequest(Socket socket) {
    var request = new Request(socket);
    var page = new Page(request);

    Thread t1 = Thread.startVirtualThread(() -> page.setWeather(Weather.fetch(request)));
    Thread t2 = Thread.startVirtualThread(() -> page.setRestaurants(Restaurants.fetch(request)));
    Thread t3 = Thread.startVirtualThread(() -> page.setTheaters(Theaters.fetch(request)));

    t1.join(); t2.join(); t3.join();
    page.send();
  }

Um ponto negativo aqui é que a Pagina deve ser thread safe e deve ser construída antes do uso dos fetches pois todos esses métodos podem alterar e acessar esse recurso ao mesmo tempo.
Nesse caso, algum tipo de sincronização ou lock terá de ocorrer (pinning nesse caso não soa tão ruim pelo contexto que a criação/set de um objeto Page é rápido)

Mais uma imagem de exemplo:

⚠️ Aviso

Como movemos coisas para a memória e trazemos-as de volta, teremos problemas se estivermos usando ponteiros diretamente, mas você provavelmente não vai fazer isso em JAVA.
Apesar disso, o bloco "synchronized", faz isso, e quando isso acontece, a task executa de maneira bloqueante na platform thread, sem ir para a heap memory como as virtual threads fazem, ou seja, o yield não acontece.
Chamamos isso de pinning, se você precisar usar "synchronized" em um bloco que leva uma quantidade considerável de tempo (milisegundos), refatore-o para usar ReentrantLock, senão você vai bloquear sua pequena quantidade de platform threads por bastante tempo :(

Adicionalmente, você pode observar com facilidade os pinnings de platform threads: New diagnostics assist in migrating code to virtual threads and in assessing whether you should replace a particular use of synchronized with a java.util.concurrent lock:

A JDK Flight Recorder (JFR) event is emitted when a thread blocks while pinned (see JDK Flight Recorder).

Habilitando no Spring

Para habilitar virtual threads no SPRING, use:

spring:
    threads:
        virtual:
            enabled: true
## ou
spring.threads.virtual.enabled=true

Essa alteração já fará com que seu servidor deixe de trabalhar com o antigo cenário de uma thread por request, possívelmente melhorando sua performance, mesmo sem muitas alterações (No caso, isso provavelmente só ocorrerá se você já estiver recebendo uma quantidade de chamadas o suficiente para esgotar sua pool de platform threads, que é 200).

Concorrência Estruturada - Feature Preview

A feature de Concorrência Estruturada, tem como foco a escrita simples de códigos
concorentes, usando o paradigma imperativo.

Em um passado distante, os códigos que eram escritos eram recheados de "go-tos", o que dificultava muito o custo de manutenção pela dificuldade de entender o fluxo de execução do programa, estar dentro de um else não significava necessariamente, que seu if falhou.

O problema disso é que código concorrente, em sua forma atual é como usar um go-to, você não consegue saber quem invocou a instrução que está rodando na thread.

✅ Objetivos

Promover um estilo de programação concorrente que pode evitar riscos comuns associados ao uso de códigos concorrentes e paralelizado

Melhorar a observabilidade desse tipo de código

❌ Não-Objetivos

Substituir maneiras de trabalhar com código concorrente, como : ExecutorService e Future.

Definir a API definitiva de Concorrência Estruturada para a plataforma java, permitindo que outras formas surjam em novas bibliotecas ou releases da JDK

Definir maneiras de compartilhar streams de dados entre diferentes threads (exemplo: canais)

Substituir o mecanismo de interrupção de thread já existente, mas pode ser no futuro.

⚡☠️ Structured Concurrency é uma Feature Preview no JAVA 21

Ou seja, essa API pode sofrer alterações ao longo do tempo, e para utilizá-la, precisamos explicitamente liberar seu uso.

Com structured concurrency, criamos um escopo onde tarefas irão rodar de maneira assíncrona com fork e join, e depois retornamos o resultado dessas operações

Papos Técnicos para nerds

O Fork-Join-Pool das Threads que as Virtuals usam

Comentamos anteriormente como as Virtual Threads funcionavam em cima de threads reais: O scheduler de virtual threads é um 'work-stealing' ForkJoinPool que opera usando FIFO mode. O paralelismo padrão do scheduler é a quantidade padrão de processadores (ou quantidade de threads dos seus processadores :) que sua máquina tem. Dá para alterar isso na prop: jdk.virtualThreadScheduler.parallelism. Esse ForkJoinPool especificamente é tunado de uma maneira diferente de um pool normal, que opera usando LIFO.

Mais

Referências

JEP 444: Virtual Threads

State of Loom

Performance and scalability analysis of Java IO and NIO based server models, their implementation and comparison, Karabyn Petro. 2019

Virtual threads: Are futures a thing of the past? - Java Magazine

The Ultimate Guide to Java Virtual Threads - Rock the JVM Blog/

CompletableFuture with Virtual threads/

Java Virtual Threads - Esse não foi usado diretamente no texto, mas foi uma boa fonte de conhecimentos.

https://www.youtube.com/watch?v=YQ6EpIk7KgY - Pelo engenheiro chefe responsável pela concepção da JEP das virtual threads.

Arquitetura de Software para devs: MVC, Hexagonal, DDD

Kauê Gatto — Mon, 13 Nov 2023 17:28:49 +0000

Arquitetura à nível de Software:

Refere-se à organização e definição de regras a serem seguidas no seu projeto em si, seja ele um microserviço, monolito ou qualquer outra parte de uma solução maior, nossa ênfase está no nível do seu serviço, um serviço seu pode seguir à risca SOLID, arquitetura hexagonal e uma PoC pode seguir o famoso: faz rápido e funcionando.

De outro lado, cuidando e decidindo se temos SOA, Microserviços, Monolitos ou qual protocolo de comunicação usamos, temos a arquitetura de soluções, o que não é o foco do artigo

Modelo Baseado em Camadas

É bem comum dividirmos nosso software em camadas, é o que fazemos na maior parte das arquiteturas de software modernas, essa divisão tem como objetivo separar partes do código que não devem interagir muito entre si exceto por alguns pontos de contato (que podem ser outras camadas), e também garantir que exista um “meio de campo” entre certas camadas, ou seja, a interface não vai falar diretamente com o banco de dados, existe um caminho para isso.

Um dos pontos negativos desses modelos é que eles não costumam definir a obrigação ou sugestão de interfaces para comunicação com serviços externos, normalmente services são totalmente acoplados à infraestrutura, em alguns casos, até mesmo temos DAO’s que implementam regras de persistência na camada de modelo. O problema disso é claro, nossas regras de negócio muitas vezes acabam acopladas à meras ferramentas, trocar o banco de dados exige que você mexa em um pedaço que deveria representar sua regra de negócio, o que não acontece em outros modelos como arquitetura hexagonal (a menos que você adapte seu padrão em camadas para ter abstrações significativas, o que é totalmente válido 🙂).

MVC

O MVC (Model-View-Controller) é um pattern arquitetural usado como um molde pra distribuição de responsabilidades em trechos de código que tratam de interfaces com o usuário (UI). Há três responsabilidades pre-estabelecidas:

View: contém a lógica que monta a UI (telas ou equivalente) e que trata a entrada de dados, recebendo eventos do usuário (clique, digitação etc.). As do usuário são repassadas para o Controller. A View pode buscar dados diretamente do Model para exibição na UL
Controller. o "meio de campo", recebe interações do usuário da View e colabora com o Model para enviar e obter dados, que são repassados para a View.
Model: o resto do código, que não tem a ver com UI. Realiza cálculos, regras de negócio, persistência, integrações com outros sistemas etc. Há diversas variações como MVP, MVVM, entre outros.

Outros exemplos → MVVM
The main thrust of the Model/View/ViewModel architecture seems to be that on top of the data (”the Model”), there’s another layer of non-visual components (”the ViewModel”) that map the concepts of the data more closely to the concepts of the view of the data (”the View”). It’s the ViewModel that the View binds to, not the Model directly.

Arquitetura Hexagonal - Ports And Adapters

A arquitetura hexagonal é uma proposta de arquitetura de software que segue lógicas de desenvolvimento de software que pensam em acoplamento e coesão, basicamente, módulos de alto nível (que possuem regras de negócio) não devem depender de implementações de módulos de baixo nível (frameworks, bibliotecas de terceiros, et cetera.). Tudo que acessa o coração / domínio / regra de negócio da sua aplicação deve passar por portas, que são basicamente interfaces que representam o que aquela biblioteca fará para você, chamamos a implementação dessas interfaces de adaptadores.

Ou seja, em um sistema de login, podemos disparar um evento em uma fila de mensagens RabbitMQ que será consumido por um outro serviço de notificação, pensando em um nível um pouco mais abstrato, esquecendo bibliotecas ou ferramentas, podemos criar uma interface de publicador de eventos e dizer que vamos usar ela, ou seja, nossa lógica de negócio precisa enviar uma notificação de cadastro e um payload, independente se rabbitMQ, kafka ou outra porta está sendo usada:

private final Notifier messagePublisher;
public class TicketService {
  public Ticket create(Ticket ticket){
    messagePublisher.Notify(TicketEventsEnum.TICKET_CREATED);
    return repository.save(ticket);
  }
}

No service, a regra de negócio de criação de um ticket é exatamente essa, note que não estou usando uma regra de rabbitMQ necessariamente, nem mesmo o seu vocabulário (normalmente usaríamos publish) o importante para a regra de criação, é enviar uma notificação!

A dependência Notifier é na realidade uma interface própria, que representa o que necessitamos, o envio de uma notificação, é uma porta.

public interface Notifier {
  void Notify(Object message);
}

O Adaptador, que é basicamente uma das opções de notificadores que vc tem é a implementação real, você poderia trocar os adaptadores e ainda assim não ter problemas no seu domínio, tendo em vista que todo adaptadores respeita a mesma interface (porta).

Imagine que você está indo viajar, o núcleo da aplicação é o conteúdo essencial da sua mala - os itens vitais que você não pode deixar para trás. Os adaptadores são os diversos compartimentos e bolsos especializados na mala, cada um projetado para acomodar diferentes necessidades, você tem um plugue para tomadas da europa, outros para os estados unidos e outra que suporta o padrão adotado na ásia (não sei nem se é diferente). Da mesma forma, os adaptadores na arquitetura hexagonal conectam o núcleo da aplicação a interfaces externas variadas, como bancos de dados, interfaces de usuário e serviços externos, esses adaptadores permitem que a aplicação funcione em ambientes diversos.

Clean Architecture

Não entrarei em detalhes pela sua complexidade e individualidades, mas saiba que tanto a clean architecture quanto a onion se baseiam no mesmo fundamento, de proteger a camada de domínio, com os mesmos princípios de abstração por interfaces, e adaptadores implementando-as

DDD - Isso não é sobre DDD

O Deisgn orientado à Domínio (Domain Driven Design / DDD) é um conceito extenso e vai além de um sugestões sobre como dividir seu código em camadas (esse nem é o foco), comentando a maneira com que o software é escrito, a linguagem utilizada no processo de fabricação, o que são as fronteiras entre suas entidades e regras de negócio e como elas devem ser implementadas, realmente fazendo com que a preocupação de domínio seja a central na construção de software.

Encare o DDD como uma prescrição de metodologia e **processo** para o desenvolvimento de sistemas complexos cujo foco é mapear atividades, tarefas, eventos e dados dentro de um domínio de problema nos artefatos de tecnologia de um domínio de solução.

Apesar disso, Evans em seu livro deu diversas sugestões arquiteturais, como por exemplo, os services, muitas vezes, mal utilizados ou interpretados. Veremos agora algumas sugestões e pontos do autor.

DDD - Sugestões Arquiteturais → e de design de código

Antes de tudo, acho importante definir o que é o domínio de uma aplicação:

Domínio:
No contexto de Engenharia de Software é o “conhecimento” utilizado em uma determinada área de aplicação, um campo específico para qual o sistema foi desenvolvido, ou seja, os problemas, regras e soluções que envolvem uma parte da aplicação, apesar disso, muitas vezes nos referimos ao domínio de negócio (núcleo de regras e conhecimentos que envolvem o negócio) somente como domínio, leve isso em consideração, porém tenha em mente que uma aplicação tem diversos domínios.

Quando o código relacionado ao domínio é distribuído por uma porção tão grande de outros códigos (espalhado), torna-se extremamente difícil distingui-los e raciocinar. Alterações superficiais na interface do usuário podem realmente alterar a lógica de negócios (alterações vazam para onde não devem).

Assim sendo:

Isole o modelo do domínio e a lógica de negócios e elimine qualquer dependência que eles possam ter na infraestrutura, na interface do usuário ou mesmo na lógica do aplicativo que não seja lógica de negócios.
Particione um programa complexo em camadas. Desenvolva um design dentro de cada camada que seja coeso e que dependa apenas das camadas abaixo. Concentre todo o código relacionado ao modelo do domínio em uma camada e isole-o do código da interface do usuário, do aplicativo e da infraestrutura. Os objetos de domínio, livres da responsabilidade de se exibir, de se armazenar, de gerenciar tarefas do aplicativo, e assim por diante, podem se concentrar em expressar o modelo do domínio. Isso permite que um modelo evolua para se tornar rico e limpo o suficiente para capturar o conhecimento essencial do negócio e colocá-lo para funcionar, sempre que uma regra de negócio surgir, o modelo de domínio deve ser o necessário por implementá-la, quem deve se adaptar às regras de negócio é a implementação, e nunca o contrário.

Dito isso, colocar as responsabilidades certas no domínio não significa que o modelo deve ser anêmico, o modelo pode (e deve) manter regras e formas para que seu escopo seja válido. Ou seja, fazemos o possível para que uma entidade de domínio nasça e continue sempre de acordo com suas regras de negócio.

Modelos Anêmicos - Um problema

Conceito muito difundido no artigo Anemic Domain Model, de Martin Fowler.

Quando falamos de modelos de domínio anêmicos dizemos de modelos onde as regras de negócio associadas à uma entidade é externa à própria entidade. Temos uma classe pedido mas o método para verificar se o pedido contém itens ou não está em um “service”, que acaba sendo uma classe que possui regras que poderiam existir dentro de uma própria entidade (se contiver somente o seu comportamento).

Classes que possuem somente atributos são classes de domínio anêmicas, idealmente, uma classe deve conter comportamento e atributos.

Podemos chamar classes JAVA ou C# que são totalmente desacoplada de outras bibliotecas ou framewrks de POCO (no C#) ou POJO (no JAVA). Por serem códigos puros escritos em java ou c#, que não deviram de uma classe base e nem retornam ou utilizam de tipos especiais, ou seja, são classes simples que sabem apenas de seu domínio, devemos sempre seguir os princípios da ignorância da infraestrutura e ignorância da persistência para essas classes.

Portanto, as entidades não devem ser associadas aos modos de exibição do cliente pois, no nível da interface do usuário, alguns dados podem ainda não ter sido validados. É por esse motivo que o ViewModel existe. O ViewModel é um modelo de dados exclusivamente para necessidades de camada de apresentação. As entidades de domínio não pertencem diretamente ao ViewModel. Em vez disso, você precisa converter entre entidades de domínio e ViewModels e vice-versa. - *Projetar um microsserviço orientado a DDD, Microsoft*

Refatorando um Domínio anêmico

Atributos distantes do comportamento

Para começar, recomendo ler o caso 1 de 3. Refatoração → Casos Usuais, depois volte aqui. De maneira geral, classes devem guardar dentro de si atributos e comportamentos, se você possui comportamentos que agem sobre os atributos de uma classe específica, costuma fazer sentido encapsulá-los dentro da classe.

Exemplo:

Class ComprarIngressoService{
    void comprar(Pessoa pessoa, Evento evento){
        ...
        if(pessoa.idade<18){
            // menor de idade
        }
        if(pessoa.getCadastro()=="ativo"){
            //
        }
    }
}

Esse tipo de validação é aparentemente inofensiva, contudo, frágil, pode causar diversas repetições no código e aumentar pontos de contato para uma possível alteração, em alguns casos, esse tipo de erro piora muito a leitura. Faz sentido que a classe Pessoa cuide de propriedades das pessoas, logo, a refatoração a seguir é possível:

Class ComprarIngressoService{
    void comprar(Pessoa pessoa, Evento evento){
        ...
        if(pessoa.maiorDeIdade()){
            // menor de idade
        }
        if(pessoa.estaAtiva()){
            //
        }
    }
}

Construtores, Builders e falta de amor aos erros de compilação

Um grande motivo para escrevermos códigos que são fortemente tipados é a possibilidade de perceber erros em tempo de compilação, erros que impedem que façamos coisas que não fazem sentido dado o contexto do que estamos tentando fazer, a semântica de string, por exemplo, entendida como cadeia de caracteres, não permite a soma de números a ela (Some um à kaue).

Dito isto, grande parte das classes de domínio não validam seu estado, muitas vezes nem em sua criação. É comum ver por ai classes com construtores vazios e códigos setters públicos (pois getters e setters teoricamente protegem o encapsulamento) isso por si só não garante que uma classe irá ser usada como esperada, veja o exemplo a seguir.

class Pessoa{
    Pessoa(){
        // construtor vazio, no java é opcional    
    }
    @Getter
    @Setter // simulando o lombok, mas pode imaginar que são métodos getter e setters públicos
    private Long  id;
    @Getter
    @Setter
    private String nome;
    @Getter
    @Setter
    private Int peso;
}

// em algum outro lugar:
Pessoa kaue = new Pessoa();
kaue.setId(1);
kaue.setNome("kaue");
kaue.setPeso(65);
// teoricamente kaue está tranquilo levando em conta que todos os campos foram preenchidos, mas e o seguinte?
Pessoa douglas = new Pessoa();
douglas.setPeso(70);

Não existe erro de compilação e nem de execução (POR ENQUANTO) aqui.

É óbvio que os setters deveriam validar se os campos foram preenchidos de seguindo um certo padrão e que faltam métodos para lidar com o objeto pessoa como indicado no ponto anterior, o modelo está anêmico, mas esse não é o foco, criamos um objeto de uma Pessoa chamado douglas, que possui apenas seu peso definido, o que provavelmente não faz sentido quando pensamos na criação de uma pessoa em um sistema, deveríamos (dependendo do negócio) ao menos forçar o preenchimento de id e nome.

class Pessoa{
    Pessoa(String id, String nome){
        // único construtor recebendo os campos opcionais.
        this.id=id;
        this.nome=nome;
    }
    @Getter
    // setter não existe mais
    private Long id;
    @Getter
    // setter pode até existir, mas nesse caso não vou criar.
    private String nome;
    @Getter
    @Setter
    private Int peso;
}

// em algum outro lugar:
Pessoa kaue = new Pessoa(1,"kaue");
kaue.setPeso(65);

Pessoa douglas = new Pessoa(); // erro
douglas.setPeso(70);

Mas e classes builders? Também não é incomum ver builders que esquecem de implementar os campos obrigatórios, para nossa felicidade, é algo simples de ser resolvido.

PessoaBuilder pessoaBuilder = new PessoaBuilder(1,"kaue"); // construtor do BUILDER tem em si os parâmetros necessários para criar a classe que constrói
// se o método para pegar o builder for um método estático, só passar em seu parâmetro
Pessoa kaue = pessoaBuilder
                                             .withPeso(70)
                       .build();

Usando o lombok @builder, podemos fazer:

import lombok.Builder;

@Builder(builderMethodName = "hiddenBuilder")
public class Person {
        @NotNull
    private String name;
    private String surname;

    public static PersonBuilder builder(String name) {
        return hiddenBuilder().name(name);
                // o nome desse builder interno é arbitrário
    }
}
// 
Person p = Person.builder("Kaue").surname("Surname").build();

Essa tática, usando o lombok ou não, tem alguns problemas e normalmente não faz sentido em classes que tem muitos parâmetros obrigatórios e até mesmo em algumas classes simples, pois depreca, mesmo que um pouco, uma das grandes vantagens que a classe builder tem, a visibilidade, imagine isso:

Endereco e = Endereco.builder("Osvaldo Albherto", "Parque Bitaru", "42", "Abilio")
.complemento("Ap 1")
.maisInformacoes("Pode entregar pro vizinho")
.build();

Somente lendo esse código, você só consegue ter certeza do complemento e maisInformacoes, os outros campos não são tão visíveis, ainda assim, como opinião pessoal, prefiro por ter esse código, que se torna um pouco menos visível mas garante o uso correto da classe, mostrando erros de compilação na própria IDE caso os atributos obrigatórios não estejam preenchidos.

Modelos Ricos: como lidar com dependências excessivas

Se sua classe POJO de domínio necessitar de bibliotecas ou outras dependências (faça-as serem interfaces 🙏), instanciá-la ficará extremamente inconveniente, para isso existe o Design Pattern: Factory

Design Pattern: Factory

F*actories são métodos (ou classes) que possuem como retorno a criação de um outro objeto*, em casos mais simples, podem ser métodos estáticos dentro da própria classe, em casos mais complexos, onde teremos diferentes dependências a serem injetadas nas classes de domínio atráves de um framework ou container de injeção de dependência, como o Spring faz, podemos usar classes.

Imagine a existência de uma classe usuário, que necessita que seu próprio email seja validado, e para isso, você quer usar uma biblioteca x ou y, você, respeitando princípios básicos, criará uma interface a qual Usuário dependerá, e fará com que a injeção de dependência passe a você uma instância do validador em algum momento, isso irá se tornar extremamente inconveniente muito rápido, portanto, podemos fazer:

public class Usuario {
    private String email;
    private EmailValidator emailValidator;

    public Usuario(String email, EmailValidator emailValidator) {
        this.email = email;
        this.emailValidator = emailValidator;
    }

    public boolean isEmailValid() {
        return emailValidator.isValid(email);
    }

    // Outros métodos da classe Usuario
}

public class UsuarioFactory {
    private final EmailValidator emailValidator;

    // Construtor com injeção de dependência!
    public UsuarioFactory(EmailValidator emailValidator) {
        this.emailValidator = emailValidator;
    }

    // Método para criar instância de Usuario usando o validador de e-mail fornecido pelo Spring (ou pelo seu framework de DI)
    public Usuario createUsuario(String email) {
        return new Usuario(email, emailValidator);
    }
}

E os Services?

Evans Descreve em seu livro três tipos de services:

Application Service:

Fornece para o usuário operações que o seu software pode executar, e controla a execução dessas operações através de chamadas a métodos de objetos das outras camadas (domínio, infraestrutura, etc.). É importante dizer que a Application Service não contém regras de negócios ou conhecimento do domínio, sendo assim, ela apenas coordena as chamadas a métodos de outras camadas e mantém o estado que reflete o progresso de uma operação para o usuário.

Application Layer: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program. - Evans DDD

Domain Services:

Fornece para a Application Service métodos que permitam a execução de operações sobre os objetos de Domínio (camada mais interna). Embora seja comum representar grande parte dos conceitos e regras principais do negócio aqui, o ideal é que esses detalhes sejam representados diretamente nos Domain Models. Sendo assim, o Domain Service deve chamar e controlar a execução de métodos dos objetos do Domain Model quando não é trivial ou lógico declarar um método diretamente no modelo de domínio

As vezes, a situação simplesmente não se trata de uma coisa.

Alguns conceitos do domínio não são naturais para serem modelados na forma de objetos.

Forçar a funcionalidade do domínio necessária para que ela seja a responsabilidade de uma Entidade ou Objeto de Valor distorce a definição de um objeto baseado em modelos ou adiciona objetos artificiais sem sentido.

Assim sendo:

Quando um processo ou transformação significativa no domínio não é uma responsabilidade natural de uma Entidade ou Objeto de Valor, adicione uma operação no modelo como uma interface autônoma declarada como Serviço. Defina um contrato de serviço, um conjunto de asserções sobre interações com o Serviço. (Veja “asserções”) Torne essas asserções participantes da Linguagem Onipresente de um Contexto Delimitado específico. Dê um nome ao Serviço, que também se torne parte da Linguagem Onipresente.
Evans - DDD

Infrastructure Services:

Fornece métodos que permitem a execução de operações sobre a infraestrutura na qual o software está sendo executado. Isso significa que esses serviços tem conhecimento sobre detalhes das implementações concretas da infraestrutura tais como: acesso a bancos de dados, acesso a rede, controle de operações de IO, acesso a hardware etc. Geralmente esse service é utilizado pelos Application Services para complementar e auxiliar suas operações, por exemplo, fornecer um método que permita a criação e controle de um buffer para realizar download de arquivos.

Contrapontos:

💡 Regardless, if your microservice or Bounded Context is very simple (a CRUD service), the anemic domain model in the form of entity objects with just data properties might be good enough, and it might not be worth implementing more complex DDD patterns. In that case, it will be simply a persistence model, because you have intentionally created an entity with only data for CRUD purposes.

Design a microservice domain model - Microsoft

Some people say that the anemic domain model is an anti-pattern. It really depends on what you are implementing. If the microservice you are creating is simple enough (for example, a CRUD service), following the anemic domain model it is not an anti-pattern. However, if you need to tackle the complexity of a microservice’s domain that has a lot of ever-changing business rules, the anemic domain model might be an anti-pattern for that microservice or Bounded Context. In that case, designing it as a rich model with entities containing data plus behavior as well as implementing additional DDD patterns (aggregates, value objects, etc.) might have huge benefits for the long-term success of such a microservice.

Microsoft resource

Aqui entendemos uma coisa que deve ser clara, não existe bala de prata na computação, faz sentido abstraírmos o SPRING, Controllers, Services e outras funcionalidades ou entedemos que nossa aplicação nasce acoplada ao SPRING e morre com ele?

Aqui, tudo cabe à você entender pontos, contrapontos e o seu contexto, no seu caso. Se sua aplicação só existe junto à infraestrutura de uma biblioteca, talvez não haja motivo para desacoplá-la, se você não vê perspectivas para deixar de usar lombok, não necessariamente precisa fazer seu modelo de domínio POJOS realmente puras use seu lombok, e seja feliz. Um projeto simples ou que necessita ser entregue muito rapidamente não usar de conceitos como Arquitetura Hexagonal, DDD, CQRS ou qualquer outro pattern não se traduz emprojeto simples ou que significa código ruim.

Referências:

The Software Architecture Chronicles

Esse blog, essa crônica em específico - é maravilhosa!! Se estiver off, procure no wayback machine.

Domain Driven Design, Eric Evans

Anemic Domain Model, Martin Fowler (Cosigned by Evans)

Sumário de Padrões e Definições do DDD - Traduzido por Ricardo Pereira Dias

Projetando um microsserviço orientado a DDD

https://www.youtube.com/watch?v=1Lcr2c3MVF4

Persistence Ignorance | DevIQ

Infrastructure Ignorance

Hexagonal Architecture, DDD, and Spring | Baeldung

RabbitMQ Com Java e Spring : Parte 2

Kauê Gatto — Mon, 13 Nov 2023 13:37:07 +0000

Nota:

Nesse momento, entraremos um pouco mais em detalhes sobre como o protocolo AMQP funciona e sobre a biblioteca de AMQP do spring, escrevi um “guia” bem básico sobre propriedades do protocolo, se quiser conferir, pode ver aqui :)

mensageria.pdf

Ou nesse link

Contexto

O Spring AMQP consiste em dois módulos principais: spring-amqp e spring-rabbit. O ‘spring-amqp’ contém o pacote org.springframework.amqp.core, que trata das principais abstrações definidas no protocolo AMQP (RabbitMQ é um broker, que implementa esse protocolo), esse pacote não se baseia em nenhuma biblioteca de clientes nem implementação de broker.

Essas abstrações então são implementadas pelos módulos específicos dos brokers (spring-rabbit). Teoricamente, como o AMQP é opera em nível de protocolo, você poderia utilizar o cliente do rabbit com outro broker, mas isso não é oficialmente suportado.

A mensagem

A mensagem ****definida no protocolo amqp é um conjunto de bytes e propriedades, passados separadamente. Para tornar o uso mais fácil, dentro do java juntamos isso em uma abstração chamada Message

public class Message {

    private final MessageProperties messageProperties;
    private final byte[] body;

    public Message(byte[] body, MessageProperties messageProperties) {
        this.body = body;
        this.messageProperties = messageProperties;
    }

    public byte[] getBody() {
        return this.body;
    }

    public MessageProperties getMessageProperties() {
        return this.messageProperties;
    }
}

A exchange

A exchange é uma outra abstração simples, é basicamente o centro de distribuição de mensagens, que envia as mensagens de acordo com suas diretrizes:

public interface Exchange {
    String getName();
    String getExchangeType();
    boolean isDurable();
    boolean isAutoDelete();
    Map<String, Object> getArguments();
}

Os tipos básicos de exchange são: direct, topic, fanout e headers. Você pode encontrar implementações para cada um dos tipos no pacote core.

A Topic exchange supports bindings with routing patterns that may include the '*' and '#' wildcards for 'exactly-one' and 'zero-or-more', respectively. The Fanout exchange publishes to all queues that are bound to it without taking any routing key into consideration.

💡 A especificação AMQP define uma exchange padrão não nomeada, todas as queues sem exchange vinculadas são automaticamente vinculadas à ela, com seus nomes como routing keys

Queues

A classe Queue também representa uma abstração desse tipo no protocolo:

public class Queue  {

    private final String name;
    private volatile boolean durable;
    private volatile boolean exclusive;
    private volatile boolean autoDelete;
    private volatile Map<String, Object> arguments;

    /**
     * The queue is durable, non-exclusive and non auto-delete.
     *
     * @param name the name of the queue.
     */
    public Queue(String name) {
        this(name, true, false, false);
    }

    // Getters e Setters omitidos
}

Bindings

Bindings são a relação entre filas e exchanges!

new Binding(someQueue, someDirectExchange, "foo.bar"); // direct exchange, routing keys fixas
new Binding(someQueue, someTopicExchange, "foo.*"); // topic exchange, usando wildcard
new Binding(someQueue, someFanoutExchange); // fanout
Binding b = BindingBuilder.bind(someQueue).to(someTopicExchange).with("foo.*"); 
// BindingBuilder é a maneira bonitinha, eu gosto, mas importa estático!

💡 Uma instância de uma Binding não trará alterações reais por ela mesma, para isso, deveremos usar a classe AmqpAdmin ou definir as bindings usando a anotação @Bean, é o que veremos a seguir

Definindo Exchanges e Bindings customizadas

Já vimos nos exemplos anteriores como as exchanges, bindings e queues são criadas, a partir de agora, só criar!

Nossas configurações, ao invés de só possuir bean de Queue, agora incluirão Exchangese Bindings

@Configuration
@Slf4j
@RequiredArgsConstructor
public class RabbitMqConfiguration {
  private final TicketQueueProperties ticketQueueProperties;

  @Bean
  public Queue queue(){
    log.info("Looking for queue: {}", ticketQueueProperties.getName());
    return new Queue(ticketQueueProperties.getName(), true);
  }
  @Bean Exchange ticketDirectExchange(){
    final String EXCHANGE_NAME = "ticket";
    log.info("Creating exchange: ticket-exchange");
    return new DirectExchange(EXCHANGE_NAME);
  }
  @Bean Binding ticketBinding(){
    log.info("Create ticket binding");
    return BindingBuilder.bind(queue()).to(ticketDirectExchange()).with(ticketQueueProperties.getName()).noargs();
  }
}

💡 Para fazer direito, provavelmente também faríamos o refactor da nossa TicketQueueProperties, provavelmente teríamos um RabbitMqProperties, onde deixaríamos configurações de filas, exchanges e bindings de maneira mais organizada!

Perfeito, já vimos nossa exchange funcionando bonito! Tudo pronto!

Só que não! Lembre-se que o nosso publisher está enviando mensagens com a routing key correta, mas para a exchange errada, vamos mudar o código para o seguinte:

rabbitTemplate.convertAndSend("direct.ticket",ticketQueueProperties.getName(),event.name());

Aqui deveríamos puxar esse nome da nossa ideal TicketQueueProperties :) para evitar esse spaghetti

Passando Objetos - Message Converters

O AmqpTemplate também define vários métodos para enviar e receber mensagens que, no fim das contas, delegam tarefas para um MessageConverter. O MessageConverter fornece um método único para cada direção: um para converter para um Message e outro para converter a partir de um Message.

Definição da interface MessageConverter:

public interface MessageConverter {
    Message toMessage(Object object, MessageProperties messageProperties)
            throws MessageConversionException;
    Object fromMessage(Message message) throws MessageConversionException;
}

SimpleMessageConverter

A implementação padrão do strategy MessageConverter é chamada de SimpleMessageConverter. Este é o conversor usado por uma instância de RabbitTemplate se você não configurar explicitamente uma alternativa.

Converts a String to a [TextMessage](https://jakarta.ee/specifications/platform/9/apidocs/jakarta/jms/TextMessage.html), a byte array to a [BytesMessage](https://jakarta.ee/specifications/platform/9/apidocs/jakarta/jms/BytesMessage.html), a Map to a [MapMessage](https://jakarta.ee/specifications/platform/9/apidocs/jakarta/jms/MapMessage.html), and a Serializable object to a [ObjectMessage](https://jakarta.ee/specifications/platform/9/apidocs/jakarta/jms/ObjectMessage.html) (or vice versa).

Trocando o Conversor

Para trabalhar com objetos serializados e desserializados para JSON, vamos usar o Jackson2JsonMessageConverter.

@Bean
public MessageConverter messageConverter() {
  return new Jackson2JsonMessageConverter();
}

Colocaremos isso tanto no consumer quanto no producer :)

Declarables, Definição Dinâmica e Declarativa de Filas

Falamos anteriormente do nossoTicketQueueProperties , que poderíamos melhorá-lo, é o que vamos fazer, na realidade, vamos substituí-lo.

Primeiro de tudo, vamos definir um formato declarativo para filas, exchanges e bindings que nos agrade, para mim:

broker:
    queues:
        ticket:
            name: default.ticket
    exchanges:
        ticket:
            name: direct.ticket
            type: direct
    bindings:
        ticket:
            exchange: direct.ticket
            queue: default.ticket
            routingKey: default.ticket

Criando um ConfigurationProperties adequado

A partir disso, vamos mapear essas propriedades em classes de uma maneira adequada. Chamarei a classe de BrokerConfigurationProperties:

package com.kaue.ticketservice.infrastructure.properties;

import jakarta.validation.constraints.NotEmpty;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Configuration;

import java.util.Map;

import lombok.Data;

@Configuration
@ConfigurationProperties(prefix = "broker")
@Data
public class BrokerConfigurationProperties {
  private Map<String, QueueProperties> queues;
  private Map<String, ExchangeProperties> exchanges;
  private Map<String, BindingProperties> bindings;

  @Data
  public static class QueueProperties {
    @NotEmpty
    private String name;
  }

  @Data
  public static class ExchangeProperties {
    @NotEmpty
    private String name;
    private String type;
  }

  @Data
  public static class BindingProperties {
    @NotEmpty
    private String exchange;
    @NotEmpty
    private String queue;
    @NotEmpty
    private String routingKey;
  }
}

Possuímos 3 maps, estruturas que linkam uma chave à sua correspondente configuração, Queue, Exchange ou Binding Properties.
Fazemos o mapeamento padrão, usando : @ConfigurationProperties(prefix = "broker"), até aqui, sem segredos 🙂

Transformando as propriedades em objetos!

A partir de agora, o terceiro passo pode parecer simples, devemos criar beans a partir das propriedades, isso não é um problema, pelo menos não se quisermos definir os Beans da maneira que fizemos antes, apesar disso, se quisermos definir uma lista de Queues, Exchanges e Bindings, devemos usar a classe Declarables, e prover um bean para ela.

Declarables: “…Used to declare multiple objects on the broker using a single bean declaration for the collection.”

@Bean
public Declarables es() {
  return new Declarables(
    new DirectExchange("e2", false, true),
    new DirectExchange("e3", false, true));
}

@Bean
public Declarables qs() {
    return new Declarables(
    new Queue("q2", false, false, true),
    new Queue("q3", false, false, true));
}

@Bean
public Declarables bs() {
  return new Declarables(
    new Binding("q2", DestinationType.QUEUE, "e2", "k2", null),
    new Binding("q3", DestinationType.QUEUE, "e3", "k3", null));
}

O exemplo acima, da documentação de referência do spring, é uma boa forma de exemplificar o uso mais simples de Declarables, vamos ver minha implementação em particular, que adiciona declarables de acordo com a BrokerConfigurationProperties

package com.kaue.ticketservice.infrastructure.configuration;

// ... ommitted

/**
 * This classes creates all queues, exchanges and bindings based on application.yaml when they're needed (called by a consumer or posted a message into).
 */
@Configuration
@Slf4j
@RequiredArgsConstructor
public class RabbitMqConfiguration {
  private final BrokerConfigurationProperties brokerConfig;
  private final List<Queue> definedQueues = new ArrayList<>();
  private final List<Exchange> definedExchanges = new ArrayList<>();

  @Bean
  public Declarables queues() {
    if (brokerConfig == null || brokerConfig.getQueues() == null) {
      return new Declarables(); // Return an empty list if no queues are configured
    }

    var queueList = brokerConfig.getQueues().values().stream()
      .filter(Objects::nonNull)
      .map(queueProperties -> new Queue(queueProperties.getName(), true))
      .toList();

    definedQueues.addAll(queueList);
    log.info("Declared queues");
    return new Declarables(queueList);
  }
  @Bean
  public Declarables exchanges() {
    if (brokerConfig == null || brokerConfig.getExchanges() == null) {
      return new Declarables(); // Return an empty list if no exchanges are configured
    }

    var exchangesList = brokerConfig.getExchanges().values().stream()
      .filter(Objects::nonNull)
      .map(exchangeProperties -> new DirectExchange(exchangeProperties.getName())) // todo use correct exchange type
      .toList();

    definedExchanges.addAll(exchangesList);
    log.info("Declared exchanges");
    return new Declarables(exchangesList);
  }
  @Bean
  public Declarables bindings() {
    if (brokerConfig == null || brokerConfig.getBindings() == null) {
      return new Declarables();
    }

    var bindingsList = brokerConfig.getBindings().values().stream()
        .map(bindingProperties -> {
          log.info("Creating binding between exchange {} and queue {} with routing key {}",
                  bindingProperties.getExchange(), bindingProperties.getQueue(), bindingProperties.getRoutingKey());
          Queue queue = findQueueByName(bindingProperties.getQueue());
          Exchange exchange = findExchangeByName(bindingProperties.getExchange());

          return BindingBuilder.bind(queue)
                  .to(exchange)
                  .with(bindingProperties.getRoutingKey())
                  .noargs();
        })
        .toList();
    return new Declarables(bindingsList);
  }

  private Queue findQueueByName (String queueName){
      return definedQueues.stream()
              .filter(queue -> queueName.equals(queue.getName()))
              .findFirst()
              .orElse(null);
    }

    private Exchange findExchangeByName (String exchangeName){
      return definedExchanges.stream()
              .filter(exchange -> exchangeName.equals(exchange.getName()))
              .findFirst()
              .orElse(null);
    }
  }

Embora grande, a implementação é relativamente simples, usamos streams para transformar as propriedades em classes reais e retornamos o Declarable como um Bean, um objeto gerenciado pelo spring.

Poderes de RabbitListener

No Spring, quando um método anotado como listener joga uma exception, as mensagens podem ser inseridas novamente na fila e reprocessadas, descartadas ou colocadas em uma Dead Letter Queue. Nada é devolvido ao emissor da mensagem.

Error Handling

Na versão 2.0 do Spring AMQP em diante, @RabbitLisetener tem 2 atributos: errorHandler ereturnExceptions, mas eles não são configurados por padrão.

Você pode usar o errorHandler para prover um Bean de RabbitListenerErrorHandler. Essa interface funcional tem um método:

@FunctionalInterface
public interface RabbitListenerErrorHandler {
    Object handleError(Message amqpMessage, org.springframework.messaging.Message<?> message,
              ListenerExecutionFailedException exception) throws Exception;
}

Aqui, por exemplo, poderíamos dizer que exceções de serviço ou fatais jogam exceções AmqpRejectAndDontRequeueException, para evitar requeue.

As you can see, you have access to the raw message received from the container, the spring-messaging Message<?> object produced by the message converter, and the exception that was thrown by the listener (wrapped in a ListenerExecutionFailedException). The error handler can either return some result (which is sent as the reply) or throw the original or a new exception (which is thrown to the container or returned to the sender, depending on the returnExceptions setting).

A citação acima comenta uma maneira de enviar exceptions de volta ao sender, se te interessar, pode ver aqui

Retries!

Podemos customizar e modificar configurações de retry indicadas dentro do nosso projeto, para isso usaremos o projeto spring-retry, vamos ver uma configuração simples no Bean do RabbitTemplate:

@Bean
public RabbitTemplate rabbitTemplate() {
    RabbitTemplate template = new RabbitTemplate(connectionFactory());

        RetryTemplate retryTemplate = RetryTemplate.builder()
                .maxAttempts(3)
                .fixedBackoff(1000)
                .retryOn(RemoteAccessException.class)
                .build();

        retryTemplate.execute(ctx -> {
            // ... do something
        });

    template.setRetryTemplate(retryTemplate);
    return template;
}

Para mais informações, veja o [spring-retry](https://github.com/spring-projects/spring-retry#using-retrytemplate)

Dead Letters

When a listener throws an exception, it is wrapped in a ListenerExecutionFailedException. Normally the message is rejected and requeued by the broker. Setting defaultRequeueRejected to false causes messages to be discarded (or routed to a dead letter exchange).

Vamos tentar seguir o que o comentário acima da documentação do spring diz:

spring:
    rabbitmq :
        ... adresses e outras configs
        listener:
            simple:
                default-requeue-rejected: false

Depois dessa configuração, as mensagens quando possuem um erro são DELETADAS, desabilitando os retries. Isso provavelmente não é o que queremos, por isso, vamos estudar as DLQ’s.

Dead Letter Queues (DLQ) são filas que possuem mensagens que tiveram sua execução falhada em algum momento, o comportamento das DLQ’s pode ser configurado no próprio broker.

Dead Letter Queues são úteis em sistemas mais críticos, onde necessitamos que um job rode de qualquer forma, onde podemos jogar mensagens de DLQ’s na exchange padrão novamente, ou pelo menos entendermos o porquê daquilo não ter sido executado, essas filas possuem diversas funções.

A maneira de definir dead letters é algo explicado dentro do protocolo AMQP, podemos apenas seguir essa configuração:

@Bean
Queue messagesQueue() {
    return QueueBuilder.durable("queue-name")
      .withArgument("x-dead-letter-exchange", "nome-exchange.dlx")
      .withArgument("x-dead-letter-routing-key", "queue-name.dlq") // nao precisa ser o nome da queue, mas é comum para direct
      .build();
}

@Bean
Queue deadLetterQueue() {
    return QueueBuilder.durable("queue-name.dlq").build();
}

No fim das contas, uma dead letter queue é uma queue normal, e uma dead letter exchange também, portanto, se uma mensagem chegar na DLX (Dead Letter Exchange) e não tiver uma routing key correta, ela não chegará na fila, tudo normal por aqui.

💡 Se tivermos uma exchange como string vazia, ela usará a exchange padrão!

Observações

Existem diversas maneiras de trabalhar com rabbitMQ, e uma infinidade de propriedades e configurações não mostradas aqui, como por exemplo: Feedback síncrono de exchanges e filas, Consumers Assíncronos, Containers Diferentes, propriedades de requeue, monitoramento de consumers, etc. Se algo fizer sentido para seu contexto, pode buscar no material de referência do Spring 🙂

Mais sobre DLQ: https://www.youtube.com/watch?v=GgIJWxk_-jM

Mais sobre exception handling: https://www.baeldung.com/spring-amqp-error-handling

Referências

https://docs.spring.io/spring-amqp/reference/html/#template-retry

https://github.com/spring-projects/spring-retry

https://www.baeldung.com/spring-amqp-error-handling

RabbitMQ com Java e Spring : Começando (pt. 1)

Kauê Gatto — Tue, 31 Oct 2023 19:33:39 +0000

Bem vindo(a)! ao meu post de RabbitMQ com JAVA. Esse post não tem como objetivo te ensinar RabbitMQ em detalhes ou até o protocolo AMQP. Na realidade, possuo um outro artigo onde comento sobre algumas peculiaridades do protocolo AMQP nesse link. De qualquer forma, na parte dois vou explicar por cima o que são filas, exchanges, bindings e seus tipos.

A ideia hoje é fazermos algo realmente simples e mão na massa:

Configurarmos nosso rabbitMQ no docker com docker-compose
Configurarmos um publisher, que envia mensagens de texto para as filas do RabbitMQ
Configurarmos um consumer, que recebe essas mensagens e as trata.

Configuração Básica

Antes de tudo, precisamos subir um servidor do Rabbit em nossa máquina local, a melhor maneira, na minha visão, de fazer isso, é usando docker, curto mais usar compose pra essas tarefas, então:

version: '3.1'

services:
  rabbitmq:
      image: rabbitmq:management
      container_name: 'rabbitmq'
      ports:
        - "5672:5672"
        - "15672:15672"

Depois disso, você pode rodar docker-compose up e ser feliz. (Você vai precisar ter docker & docker compose instalados).]
Verifique sua instalação em localhost:15672

Definindo propriedades para a fila

Gosto de organizar propriedades em um ConfigurationProperty (principalmente quando elas podem crescer, o que é o caso), que busca informações do application.properties ou application.yaml

Nesse caso em específico, vou fazer algo bem simples.

package com.kaue.ticketservice.infrastructure.properties;

import lombok.Getter;
import lombok.Setter;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

@ConfigurationProperties("broker.queue.ticket")
@Component
@Getter
@Setter
public class TicketQueueProperties {
  private String name;
}

broker:
    queue:
        ticket:
            name: default.ticket

Poderíamos ter múltiplas entries, e cada queue poderia ter outras propriedades além de name (faremos isso na parte 2 😈):

broker:
  queues:
    ticket:
      name: default.ticket
      durable: true
      autoDelete: false
      exclusive: false
    otherQueue:
      name: other.queue
      durable: false
      autoDelete: true
      exclusive: true

Se quiser adicionar mais filas, definiria uma classe com as configurações para cada fila e definiria o ConfigurationProperties mais ou menos assim:

@Component
@ConfigurationProperties(prefix = "broker.queues")
public class QueueProperties {

    private Map<String, QueueConfig> queue;
...
}

Mas a princípio, vamos atuar só com ticket e name, do jeito que passei anteriormente.

Definindo a conexão com o Rabbit

No seu application yaml ou properties, adicione:

spring:
  rabbitmq:
    addresses: ${amqpURL:amqp://guest:guest@localhost}

Nesse caso, se a variável de ambiente amqpURL existir, ela será utilizada, caso contrário, será utilizado o padrão guest:guest, que funcionará perfeitamente com o docker compose apresentado anteriormente, então não precisa mexer se não for usar rabbit cloud ou tiver configurados as credenciais :)

Adicionando a dependência Spring-Amqp

O RabbitMQ é uma ferramenta que implementa regras do protocolo AMQP, portanto, usaremos o Spring AMQP como dependência para configurar o nosso Rabbit!

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-amqp</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.amqp</groupId>
            <artifactId>spring-rabbit-test</artifactId>
            <scope>test</scope>
        </dependency>

Criando uma Configuração Básica para Beans do Rabbit

O Spring boot trabalha com beans, que são basicamente objetos os quais ele instancia e gera, nesse caso, vamos prover configurações de beans do rabbit para o SPRING tomar conta, ou seja, criando um bean do tipo Queue, uma fila será criada automaticamente

@Configuration
@Slf4j
@RequiredArgsConstructor
public class RabbitMqConfiguration {
  private final TicketQueueProperties ticketQueueProperties;

  @Bean
  public Queue queue(){
    log.info("Looking for queue: {}", ticketQueueProperties.getName());
    return new Queue(ticketQueueProperties.getName(), true);
  }
}

⚠️ Para evitar confusão:

Estou usando RequiredArgsConstructor com um campo final: TicketQueueProperties, RequiredArgsConstructor faz com que exista um construtor que contenha todos os campos final nele, portanto, como é o único construtor, o Spring Boot o usará e automaticamente irá inserir a dependência TicketQueueProperties correta, o resultado é o mesmo que o @Autowired, mas a injeção via construtor é mais recomendada que o uso de Autowired ☝️🤓!
Aqui, podemos definir diversos beans, configurações de outras filas e exchanges, et cetera, um método para cada Bean;

Definindo o primeiro Publisher

Aqui vamos usar a composição e injetar na nossa classe uma instância de RabbitTemplate, depois, usar o método publish. Nesse caso, vamos utilizar a exchange padrão, e o nome da fila será o primeiro parâmetro, sendo o segundo a mensagem em si.

// ommitted 
import lombok.AllArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.amqp.rabbit.core.RabbitTemplate;

@Slf4j
@RequiredArgsConstructor
public class RabbitTicketPublisher implements MessagePublisher {
  private final TicketQueueProperties ticketQueueProperties;
  private final RabbitTemplate rabbitTemplate;

  @Override
  public void publish(Text text) {
    log.info("Notifying queue: {} of text{}", ticketQueueProperties.getName(), text);
    rabbitTemplate.convertAndSend(ticketQueueProperties.getName(),text);
  }
}

MessagePublisheré uma interface própria que defini em meu domínio, para desacoplar a camada de infraestrutura, deixei apenas um método publish, onde enviamos os eventos e/ ou mensagens para algum lugar, as implentações sabem que lugar é esse.

Definindo a injeção de dependências.

De maneira similar ao que já vi em C#, optei por cuidar da DI mais manualmente:

// ommitted

@Configuration
@AllArgsConstructor
public class DIConfiguration {
  private TicketRepository ticketRepository;
  private TicketQueueProperties ticketQueueProperties;
  private RabbitTemplate rabbitTemplate;
  @Bean
  public TicketService ticketService() {
    return new TicketService(ticketRepository, ticketsMessagePublisher());
  }
  @Bean
  public MessagePublisher ticketsMessagePublisher(){
    return new RabbitTicketPublisher(ticketQueueProperties, rabbitTemplate);
  }
}

Poderíamos também criar uma interface para cada publisher, mas não sei o quanto gostaria dessa abordagem, talvez haja algo melhor, mas para mim, cuidar da desambiguação de Beans dessa forma não está sendo um problema (por hora)

O Primeiro Consumer:

Aqui, vamos definir que estamos ouvindo a fila de nome X pela annotation @RabbitListener.

@Slf4j
@Component
public class TicketConsumer {
  @RabbitListener(queues = "${broker.queue.ticket.name}")
  public void listenEmailQueue(@Payload String text){
    log.info("Received: {}", text);
  }
}

Aqui estou usando o @Value ao invés do configuration properties para exemplificar, sei que diversas pessoas preferem essa abordagem!

Resultado

Parte 2 : O que veremos

O que são filas, exchanges e bindings
Definição automática elegante de filas, exchanges e bindings via application yaml usando declarables
Enviando objetos!
Outros super poderes do protocolo (introdução) : Retries, DLQ, DLXZ

Referências

https://docs.spring.io/spring-amqp/reference/html/#template-retry

Encapsulamento: O Básico que todo jr. precisa saber!

Kauê Gatto — Wed, 25 Oct 2023 23:15:24 +0000

Leitura no Notion: Boas práticas
Leitura no Notion: Mais sobre encapsulamento

Mudanças em Cascata, Menos pontos de contato

Encapsulamento é um princípio fundamental da programação orientada a objetos (POO) que ajuda a controlar o acesso e a modificação de dados dentro de uma classe. Ele se refere à prática de esconder os detalhes de implementação de uma classe de códigos externos e expor apenas uma interface pública para interagir com a classe. Isso pode ajudar a evitar mudanças em cascata em um sistema de software limitando o número de pontos de contato entre diferentes partes do código.

Uma maneira de alcançar o encapsulamento (pelo menos em uma linguagem OO) é usando modificadores de acesso como "private" ou "protected" em campos e métodos de classe. Isso pode evitar que códigos externos acessem ou modifiquem diretamente o estado interno da classe e forçar o uso de métodos ou propriedades públicas que fornecem uma forma controlada de interagir com a classe.

Essa não é a única maneira e nem todos os atributos de uma classe devem ter cegamente getters e setters, faz sentido uma pessoa depois de sua criação ter seu id alterado? Esse setter tem que existir, realmente? Outra ocasião importante que indica falta de encapsulamento é comentada no ponto 1 do capítulo de 3. Refatoração → Casos Usuais.

class MyClass {
    private int data;

    public int getData() {
        return data;
    }

    public void setData(int newData) {
        data = newData;
    }
}

O encapsulamento também pode ser usado para evitar mudanças em cascata mantendo o número de pontos de contato entre diferentes partes do código o mínimo possível. Ou seja, ao invés de termos em 5 lugares diferentes o código Float.parseFloat(getData()) poderíamos encapsular isso dentro de um método na classe Data se isso for uma regra de Data ou um comportamento relacionado à ela (mesmo que não seja, provavelmente é um comportamento de alguma outra classe). Depois dessa refatoração, ao mexermos nesse método, cuidaremos dos 5 pontos que o utilizam, ao invés de ficar buscando por ai a linha de Float.parseFloat(getData()) e quebrarmos o código pois não encontramos uma ocorrência.

Devo abstrair um determinado parâmetro/retorno?

Já dissemos muito sobre abstrações e encapsulamento, mas quando você deve abstrair um certo parâmetro ou retorno? Aquele atributo String CPF na sua classe é realmente prejudicial? Se sim, vale a pena criar uma classe para defini-lo?

Suponha que você precise criar um objeto Usuário, que tem como parâmetro do construtor um nome e senha.

class Usuario{
    ...
    public Usuario (String nome, String senha){}
}
Usuario user1 = new Usuario("kaue", "123456");

Nesse caso, como você pode garantir que usuário deve receber sua senha como plain text, e não depois de passar por um hash? Ou que a senha deve ter ao menos 6 caracteres, isso foge da lógica e semântica estabelecida pela tipo String, apesar disso, não é uma validação que dá muito trabalho, um simples length já resolveria o problema do tamanho, nesse caso, não acho que valeria criar uma classe somente para isso, mas quanto ao problema do hash, como validaríamos que o cliente usou corretamente o construtor e passou uma senha como plain text?

É simples, somente ver a implementação da classe Usuário, mas se isso não está claro, temos ai um code smell, uma espécie de acoplamento mental. Se você não tivesse acesso à Usuário, não teria como adivinhar. Nesse caso em específico, mudar o nome da variável para plainText seria uma solução caso.

Contudo, se a solução não for tão simples, acredito que normalmente passa a valer a pena criar uma classe de domínio para o parâmetro (ou retorno). Uma classe Senha com um construtor privado e métodos factory seria uma alternativa.

Trazendo isso para um exemplo real, durante o handling de metadatas as guardávamos como Map<String,Object> , repetidos em diversos lugares, apesar disso, usávamos o Map em seu exato contexto, sem a necessidade de métodos a mais além dos próprios do Map e o seu contexto e significado era exatamente o que um map representava, nesse caso, não sentimos necessidade de abstrair o tipo.

Protegendo Fronteiras

As fronteiras são a parte do seu software que agem como portas ao mundo externo. No caso de uma API, os seus clientes e pessoas que chamam a API também são externos, nenhum dado externo deve ser confiado.

Proteger as fronteiras de um software refere-se a garantir que as interfaces externas e entradas do software sejam validadas e sanitizadas adequadamente para evitar ataques maliciosos ou entradas inesperadas. Isso é uma parte importante da segurança de software e pode ajudar a prevenir problemas como SQL Injection, cross-site scripting (XSS) e outros tipos de ataques de injeção.

Uma das principais partes de proteger as fronteiras de software é a validação de entrada (input validation). Isso envolve verificar todos os dados de entrada para garantir que eles atendam a certos critérios antes de serem processados. Por exemplo, uma entrada de formulário pode ser necessária para ter um certo comprimento ou estar em um formato específico. Isso pode ajudar a prevenir erros e comportamentos inesperados, além de proteger contra entradas maliciosas.

Outra parte importante de proteger as fronteiras de software é a sanitização. Isso envolve remover ou modificar qualquer elemento potencialmente prejudicial de dados de entrada. Por exemplo, uma aplicação web pode sanitizar a entrada de usuários para remover qualquer código JavaScript ou HTML que possa ser usado para realizar um ataque cibernético.

O DDD (Domain Driven Design) também desempenha um papel importante na proteção das fronteiras de software. O DDD é uma abordagem de design de software que se concentra no domínio empresarial e enfatiza a importância de criar uma separação clara entre a lógica do domínio e os detalhes técnicos da implementação. Isso pode ajudar a garantir que as interfaces externas do software sejam bem definidas e fáceis de entender, o que pode tornar mais fácil validar e sanitizar entradas.

Serializar classes de domínio → não fazer

Ao expor os objetos do domínio através de uma API, serializá-los e enviá-los diretamente para o cliente como uma resposta, pode levar a uma série de problemas:

O cliente pode potencialmente modificar o estado do objeto do domínio e violar as regras do domínio.
O objeto do domínio pode conter informações sensíveis que não devem ser expostas ao cliente.
O objeto do domínio pode conter informações que não são relevantes para o cliente e podem levar à coleta excessiva de dados.

Para evitar esses problemas, é recomendado criar um DTO (Objeto de Transferência de Dados) separado que é especificamente projetado para a API, ele deve conter apenas as informações que o cliente precisa e não deve conter nenhum comportamento ou métodos que possam mudar o estado do objeto do domínio. Isso ajudará a proteger a integridade do modelo de domínio e manter o cliente desacoplado dos detalhes de implementação interna dos objetos do domínio.

Princípio: Favorecemos coesão através do encapsulamento

O Básico

O Encapsulamento é basicamente o ato de juntar comportamentos e estados que fazem sentido no mesmo lugar, garantindo maior coesão ao código, é um conceito básico que precisa ser dominado. Veja esse código em um repositório de um framework da Apache

for (Address address : vcard.getAddresses()) {
                    boolean workAddress = false;
                    for (AddressType addressType : address.getTypes()) {
                        if (AddressType.PREF.equals(addressType) || AddressType.WORK.equals(addressType)) {
                            workAddress = true;
                            break;
                        }
                    }
                    if (!workAddress) continue;

Sem entender muito do código e de seu contexto, já somos capaz de refatorar isso de uma maneira melhor, poderíamos simplesmente usar:

if(!adress.hasWorkAdress()) continue;

Com isso, o código escrito na classe ficaria mais legível e a função de descobrir se há endereço de trabalho ou não, passa a ser da classe Adress e pode ser replicado sem problemas através de toda a aplicação. Se decidirmos mudar a regra de negócio no estado atual, teríamos que verificar por esse imenso código esparramado por todo o programa, o que não acontece no código refatorado.

Apenas com essa alteração:

O service fica mais legível
O service fica mais testável
O código é reaproveitado e muda junto com apenas um ponto de contato (dentro da classe Adres)
O service tem maior complexidade
- A complexidade não surge, ela é distribuída, a regra já existe.

Como podemos detectar isso? Um forte indicativo que algo está estranho é estarmos usando um estado interno e aplicando lógica em cima desse estado interno fora de sua classe.

Métodos privados também podem indicar esse tipo de comportamento, talvez até mesmo a necessidade do nascimento de novas entidades.

private Person createUserAccount(String username, Collection<GrantedAuthority> authorities,PersonAttributesLookup personAttributesLookup) {
        Person person = null;

        if (hasAccountCreationPermission(authorities)) {
            person = new Person();
            person.setEnabled(true);
            person.setUsername(username);

            try {
                // Get the Person Attributes to create the person
                final PersonAttributesResult attr =
                        personAttributesLookup.lookupPersonAttributes(username);
                person.setSchoolId(attr.getSchoolId());
                person.setFirstName(attr.getFirstName());
                person.setLastName(attr.getLastName());
                person.setPrimaryEmailAddress(attr.getPrimaryEmailAddress());

                ensureRequiredFieldsForDirectoryPerson(person);
                person = create(person);
                externalPersonService.updatePersonFromExternalPerson(person, false);
                LOGGER.info("Successfully Created Account for {}", username);

            } catch (final ObjectNotFoundException onfe) {
                ...
            }

Refatorando:

                person.setSchoolId(attr.getSchoolId());
                person.setFirstName(attr.getFirstName());
                person.setLastName(attr.getLastName());
                person.setPrimaryEmailAddress(attr.getPrimaryEmailAddress());
// passa a se tornar
public Class Person{
    ...
    Person setAttributesBasedOnAttributesResult(PersonAttributesResult attr){
                this.person.setSchoolId(attr.getSchoolId());
                this.person.setFirstName(attr.getFirstName());
                this.person.setLastName(attr.getLastName());
                this.person.setPrimaryEmailAddress(attr.getPrimaryEmailAddress());

    }
}
// seria usado:
person.setAttributesBasedOnAttributesResult(attr);

Somente nessa alteração, já travamos setters que podem não ser interessantes para o negócio (como alterar o schoolId sem alterar o emailAdress, se isso for uma regra existente), ou seja, o código antigo estava desprotegido e acoplado mentalmente à alguma regra externa, precisamos sempre que atualizarmos o primeiro nome atualizar também o segundo? não sei. Se sim, podemos fazer com que o encapsulamento garanta isso.

Outro ponto de refatoramento em Person é essa parte:

        person = new Person();
        person.setEnabled(true);
        person.setUsername(username);

Talvez os métodos de setEnabled e setUsername sejam necessários, ou seja, não faz sentido criarmos um usuário sem Username e desabilitado, por que isso não faz parte do construtor? Esses setters provavelmente nem deveriam existir, com os atributos setados no próprio construtor. Tratamos isso no capítulo de refatoração

O código final poderia ficar:

private Person createUserAccount(String username, Collection<GrantedAuthority> authorities,PersonAttributesLookup personAttributesLookup) {
        Person person = null;
        if (hasAccountCreationPermission(authorities)) {
            person = new Person();
            try {
                // Get the Person Attributes to create the person
                final PersonAttributesResult attr =
                        personAttributesLookup.lookupPersonAttributes(username);
                person.setAttributesBasedOnAttributesResult(attr);

                ensureRequiredFieldsForDirectoryPerson(person);
                person = create(person);
                externalPersonService.updatePersonFromExternalPerson(person, false);
                LOGGER.info("Successfully Created Account for {}", username);

            } catch (final ObjectNotFoundException onfe) {
                ...
            }

Disclaimer!

Não leve tudo que leu aqui como verdades absolutas ou regras a serem seguida em 100% dos casos, não existe martelo de ouro nem bala de prata. Se houver algum questionamento ou sugestão, pode deixar aqui!

Referências:

Encapsulamento para ganhar mais coesão: O feijão com arroz que precisa estar dominado

OOP E Solid para ninjas - Casa do código - Aniche

Desbravando SOLID - Casa do Código - Aquiles

Features e Refactors Seguros com Java e SPRING: 2 dicas simples

Kauê Gatto — Wed, 25 Oct 2023 21:33:05 +0000

Contexto

Quando trabalhando em sistemas reais, temos que nos preocupar com a segurança de nosso código, pontos específicos de nosso código podem ser mais suscetíveis a falhas, mudanças de uma camada de baixo nível (infraestrutura) podem acarretar em problemas caso haja grandes alterações ou até mesmo uma mudança de vendor. Nesse breve artigo irei discutir duas atividades bem frequentes na minha rotina no Bees/AmBev

1. Features Toggle

Em diversos momentos, faz sentido que uma feature seja facilmente desligada ou não usando um toggle, fazendo com que essa alteração não precise de um deploy, dando mais agilidade e segurança à sua alteração.
Para isso temos algumas opções, podemos usar variáveis de ambientes ou até mesmo guardar o valor no banco de dados.
Uma maneira fácil de implementar em Spring é simplesmente puxar os dados de seuapplication.properties ou application.yaml

No Spring

Opção 1: @Value

Essa opção é particularmente útil para configurações mais simples, que possuem apenas um campo (ex: Enabled) e não são usadas em diversos lugares.
Yaml:

features:
    algumaFeature:
        enabled: true
    outraFeature:
        enabled: true

Spring:

@Value("${features.algumaFeature.enabled}")
private Boolean valueFromFile;

Opção 2: @ConfigurationProperties

Melhor para cenários mais complexos, ou quando a propriedade é usada em diversos lugares.
Yaml:

broker:
    queues:
        ticket:
            name: default.ticket
    exchanges:
        ticket:
            name: direct.ticket
            type: direct
    bindings:
        ticket:
            exchange: direct.ticket
            queue: default.ticket
            routingKey: default.ticke

Spring:

@Configuration
@ConfigurationProperties(prefix = "broker")
@Data
public class BrokerConfigurationProperties {
  private Map<String, QueueProperties> queues;
  private Map<String, ExchangeProperties> exchanges;
  private Map<String, BindingProperties> bindings;

  @Data
  public static class QueueProperties {
    @NotEmpty
    private String name;
  }

  @Data
  public static class ExchangeProperties {
    @NotEmpty
    private String name;
    private String type;
  }

  @Data
  public static class BindingProperties {
    @NotEmpty
    private String exchange;
    @NotEmpty
    private String queue;
    @NotEmpty
    private String routingKey;
  }
}

Aqui basta você fazer o mapeamento das classes de acordo com suas propriedades. Se houver dificuldade, é uma tarefa em que alguma AI provavelmente vai lidar com facilidade.

2. Diferentes Beans de Infraestrutura! Permita um rollback fácil

Em um código ideal, a sua camada de domínio provavelmente estará desacoplada de sua camada de infraestrutura por meio de interfaces. Se isso não faz sentido para você, recomendo meu post de SOLID :)
Continuando, com um código com módulos de alto e baixo nível desacoplados, conseguimos mudar a infraestrutura sem mexer no domínio. Isso nos dá a liberdade de gerenciar os beans que sua classe de domínio irá usar com mais facilidade, pois todas as implementações de infraestrutura irão respeitar a interface.

@AllArgsConstructor
public class TicketService {
  private final TicketRepository repository;
  private final Notifier messagePublisher;
  public List<Ticket> findAll(){
    return repository.findAll();
  }
  public Ticket findById(String Id){
    return repository.findById(Id).orElseThrow(
            () -> new TicketNotFoundException("Ticket not found")
    );
  }
  public Ticket save(Ticket ticket){
    messagePublisher.Notify(TicketEventsEnum.TICKET_CREATED);
    return repository.save(ticket);
  }
}

Temos aqui um Simples Service, tendo suas dependências injetadas via construtor pelo SPRING. Note que nosso serviço conhece regras de negócio, dentre elas, quando um ticket é criado, ele tem que notificar algo, e tem que guardar em algum lugar (repository pode cuidar de mongoDB, MySQL, et cetera.)
Note que se tivermos um repositório com código específico do MySQL e quisermos migrar para um código com Spring Data JPA, teremos que mudar a camada de infraestrutura (resumidamente, vamos escrever mais código de Repositório), mas nossa regra de negócio é a mesma.
Imagine agora que essa camada é um ponto crítico da sua aplicação, caso a implementação que você fez com tanta boa vontade dê errado, você terá que fazer um rollback.

Definindo os Beans Manualmente

Ao invés de definir os repositórios com @Component, como teremos dois repositórios, o Spring não saberá com qual Bean lidar.
Temos diversas maneiras de fazer a desambiguação de Beans, dentre elas, prioridades, primary, qualifier, aqui vou para uma abordagem simples, apenas para exemplificar a feature.
No meu yaml, irei definir uma propriedade:

repository:
    type: ${DEFINED_REPOSITORY:mysql}

Caso exista uma variável de ambiente chamada DEFINED_REPOSITORY, ela será o padrão para o tipo do meu repositório, caso contrário, será mysql, como um fallback. (No caso, escolhi deixar o MySQL como fallback pois teoricamente ele é o repositório testado e já em produção).
Perfeito, agora vamos definir qual bean utilizar:

@Configuration
public class RepositoryConfiguration{

  @Value("${repository.type}")
  private String repositoryType;

  @Bean
  public TicketRepository ticketRepository (){
    if("mysql".equalsIgnoreCase(repositoryType)){
       return new MySQLTicketRepository();
    }
    if("spring".equalsIgnoreCase(repositoryType)){
      return new JpaTicketRepository();
    }
    return new MySQLTicketRepository(); // fallback
  }
}

Outra maneira de fazer esse tipo de configuração é usar profiles do Spring.

Obrigado!

Obrigado, espero que o breve artigo tenha sido útil. Escrevi em 20 minutos e não o revisei, então se houver algum problema, pode me avisar :)

SOLID! Um post aprofundado

Kauê Gatto — Thu, 28 Sep 2023 23:59:57 +0000

Leitura no Notion: SOLID

Sei que existem 1 milhão de posts sobre SOLID, considero esse "guia" um pouco fora do comum pelo seu aprofundamento, tentei esclarecer todas as dúvidas que tinha ou poderia ter e sempre trazer exemplos, além de usar boas referências. Espero que esse post seja o seu guia definitivo de SOLID, assim como é para mim!

O que é SOLID?

SOLID é um Acrônimo para 5 boas práticas e/ou princípios que envolvem o desenvolvimento de um bom código orientado à objetos, não quero me estender na origem, vamos para os princípios!

Single Responsability Principle

O nome, embora auto-explicativo e que muitas vezes levava esse princípio a ser explicado como “Uma classe deve ter uma, e apenas uma responsabilidade” não é necessariamente o que você deve pensar na hora de implementá-lo. Entenda esse padrão como : “Uma classe deve ter um, e apenas um motivo para mudar”. Ou seja, não crie uma classe com a função de Emitir Nota Fiscal, crie uma classe NotaFiscal, e garanta que apenas coisas que envolvem o domínio de Nota Fiscal irão altera-lá, a mudança da emissão não muda o seu domínio de Nota Fiscal. Se uma alteração na impressora fizer a classe Nota Fiscal ser alterada, algo está incorreto.

A questão principal do SRP é o motivo para uma classe ser modificada. E esse motivo para mudança, em geral, está relacionado a um grupo de usuários ou stakeholders, que Uncle
Bob chama de atores. - Desbravando Solid

Levando em conta o que dizemos acima, também podemos dizer que o SRP pode ser definido por: “Um módulo deve ser responsável por um , e apenas um ator”. O ator que se importa com a função da emissão nota fiscal é o setor de vendas, o ator que se importa com suas horas extras, o rh, o ator que se importa com salvar no banco por id é a implementação de persistência.

Cada "interessado", de negócio ou técnico, faz com que a classe tenha uma responsabilidade diferente.

Identificar classes que mudam por diversos motivos (ou atores) é simples, a coesão pode ser uma das métricas utilizadas:

Classes coesas têm uma característica semelhante: os conceitos que essas classes representam estariam relacionados e separá-los seria pouco natural. O SRP, no fim das contas, é uma outra maneira de falar sobre a necessidade de código coeso. - Desbravando Solid

Aniche (OOP E SOLID para ninjas) sugere que, para encontrar classes pouco coesas, devemos procurar classes que:

Possuem muitos métodos diferentes.
São modificadas com frequência.
Não param nunca de crescer.

Outro fator importante é perceber a duplicação (ou pior, repetição) de código. Se seu código possui partes repetidas diversas vezes, tenha isso como um forte indicativo que essa responsabilidade provavelmente deveria estar encapsulada em algum lugar (e muito provavelmente em uma classe).

Portanto, se seu sistema pega os dados, busca coisas no banco, salva como ePUB ou PDF, tudo em uma classe só, ele provavelmente não é coeso e muito menos segue o SRP. Um exemplo disso é que toda vez que a maneira que um pdf for gerado houver de mudar, você terá que mexer nessa classe principal, e se você tiver que repetir essa alteração em diversos pontos onde o código está repetido (o que já não é um bom indicador), você provavelmente terá problemas em algum momento (e mesmo que não tenha, sua manutenção definitivamente não está facilitada).

Caso real

Recentemente ajudei um amigo em um projeto pessoal, onde ele enviava emails para a confirmação de cadastro de usuários, todas essas responsabilidades ficavam dentro da mesma classe Usuário (Gerar token, enviar email, registrar usuário).
A partir daí, trabalhamos para termos um código mais coeso, no momento em que um usuário é registrado, ele envia um evento de registro de usuário (o que é só um aviso falando: cadastrei um usuário).
Com isso, uma classe chamada enviarEmailListener se prontificava a ouvir eventos de registro e alteração de senha de usuário e ela era a responsável por enviar emails.
Portanto, com o refactor, a classe de Usuário não se preocupa com o que acontece após o registro do usuário, ela apenas notifica que isso aconteceu.
Outro ponto de melhoria nisso foi a possibilidade de tornar o envio do email assíncrono, então para cadastrar um usuário, não precisavamos esperar o serviço de email fazer sua ação, ela é independente (nesse caso, não fazia sentido ser uma transação, o cadastro de um usuário não depende do email, se um erro ocorrer nessa etapa, ele pode só pedir outro email)

Note que se tivermos mais ocasiões onde devemos enviar emails de usuário (além de cadastro e alteração de emails) podemos apenas adicionar um novo evento a ser ouvido pelo listener e se precisarmos mudar a forma de enviar email, mudamos apenas em um único método (o que aumenta MUITO a capacidade de manter o código), essa é a função do SRP.

Open-Closed Principle

Software entities ... should be open for extension, but closed for modification.

A module will be said to be open if it is still available for extension. For example, it should be possible to add fields to the data structures it contains, or new elements to the set of functions it performs.

Essas citações trazem uma noção base do que o OCP quer dizer, nosso código deve estar sempre pronto para evoluir. e de maneira natural, não devemos sentir a necessidade de modificar muitos arquivos diferentes, ou mesmo procurar (usando o CTRL+F, por exemplo) os lugares que devem ser alterados.

A segunda parte diz sobre ser fechada para modificação. nesse aspecto, podemos entender que elas não devem ter seu comportamento alterado a todo momento.

Um exemplo

public class CalculadoraDePrecos {
    public double calcula(Compra produto) {
        Frete correios = new Frete();
        double desconto = 0.0; // Inicialize desconto com um valor padrão

        if (REGRA 1) {
                    // faz algo            
        }

        if (REGRA 2) {
                    // faz algo            
        }

        return produto.getValor() * (1 - desconto) + frete;
    }
}

Note que sempre que adicionarmos regras de frete, nosso código precisará alterar a classe calculadora de preços, incluindo um novo IF, ou seja, a classe que implementar a regra de frete está acoplada à Calculadora de Preços

Uma segunda implementação comum é colocar os ifs dentro das classes
específicas. Por exemplo, a classe Frete passaria a ter as diferentes regras de negócio (os mesmos if-else). Apesar de ficar melhor, continua claro que não é a melhor abordagem.

Melhorando

Se temos diferentes regras de desconto e de frete, basta criarmos interfaces que as representam:

public interface TabelaDePreco {
    double descontoPara(double valor);
}
public class TabelaDePreco1 implements TabelaDePreco { }
public class TabelaDePreco2 implements TabelaDePreco { }
public class TabelaDePreco3 implements TabelaDePreco { }


public interface ServicoDeEntrega {
    double para(String cidade);
}
public class Frete1 implements ServicoDeEntrega {}
public class Frete2 implements ServicoDeEntrega {}
public class Frete3 implements ServicoDeEntrega {}

"Veja que essa simples mudança altera toda a maneira de se lidar com a classe. Com ela 'aberta', ou seja, recebendo as dependências pelo construtor, podemos passar a implementação concreta que quisermos para ela. Se passarmos a implementação TabelaDePreco1, e invocarmos o método calcula(), o resultado será um; se passarmos a implementação TabelaDePreco2 e invocarmos o mesmo método, o resultado será outro." (ANICHE, 2015).

public class CalculadoraDePrecos {
    private TabelaDePreco tabela;
    private ServicoDeEntrega entrega;

    public CalculadoraDePrecos(TabelaDePreco tabela, ServicoDeEntrega entrega) {
        this.tabela = tabela;
        this.entrega = entrega;
    }

    public double calcula(Compra produto) {
        double desconto = tabela.descontoPara(produto.getValor());
        double frete = entrega.para(produto.getCidade());
        return produto.getValor() * (1 - desconto) + frete;
    }
}

💡 Exemplo do Livro OOP e SOLID para Ninjas

Note que aqui trabalhamos também com a inversão de dependências (DIP), o “D”, do SOLID.

"Se o OCP declara o objetivo de uma arquitetura OO, o DIP declara o seu mecanismo fundamental."

Se você ainda não leu sobre o DIP, continue lendo o post, mais tarde revisite esse ponto, vai fazer sentido 😃

Abstrações e Capacidade de Extensão

"O que discutimos aqui, de certa forma, mistura-se com a discussão do capítulo anterior sobre estabilidade e inversão de dependências. As interfaces (abstrações) TabelaDePreco e ServicoDeEntrega tendem a ser estáveis. A CalculadoraDePrecos é uma implementação mais instável e que só depende de abstrações estáveis. Pensar em abstrações nos ajuda a resolver o problema do acoplamento e, de quebra, ainda nos ajuda a ter códigos facilmente extensíveis. Isso é programar orientado a objetos. É lidar com acoplamento, coesão, pensando em abstrações para nossos problemas. Quando se tem uma boa abstração, é fácil evoluir o sistema. Seu sistema deve evoluir por meio de novas implementações dessas abstrações, previamente pensadas, e não por meio de diversos ifs espalhados por todo o código." (ANICHE, 2015).

Design Pattern: Command

Não vou me aprofundar em patterns nesse post, mas acho legal repassar alguns exemplos que vi no material base

public class EmissorNotaFiscal  {
        private RegrasDeTributacao  tributacao;
        private LegislacaoFiscal    legislacao;
        private List<AcaoPosEmissao>    acoes;
        //...
        public  NotaFiscal  gera(Fatura fatura) {
                List<Imposto>   impostos    =   tributacao.verifica(fatura);
                List<Isencao>   isencoes    =   legislacao.analisa(fatura);
                //  método auxiliar
                NotaFiscal  nota    =   aplica(impostos,    isencoes);
                //  modificado
                for (AcaoPosEmissao acao:   acoes)  {
                        acao.faz(nota);
                }
                return  nota;
        }

Exemplo do livro Desbravando Solid (AQUILES, 2022)

Note que é muito fácil adicionar novos comportamentos depois de uma nota fiscal ser emitida, podemos simplesmente adicionar um objeto na lista de ações, isso caracteriza o padrão Command.

Recomendo a leitura mais aprofundada em: https://refactoring.guru/design-patterns/command

Design Pattern: Strategy

Exemplo de: https://en.wikipedia.org/wiki/Strategy_pattern

"Strategy permite que o algoritmo varie independentemente dos clientes que o utilizam. Strategy é um dos padrões incluídos no influente livro "Design Patterns" de Gamma et al., que popularizou o conceito de usar padrões de design para descrever como projetar software orientado a objetos flexível e reutilizável. Adiar a decisão sobre qual algoritmo usar até o tempo de execução permite que o código chamador seja mais flexível e reutilizável."
https://en.wikipedia.org/wiki/Strategy_pattern

public interface IComportamentoDeFreio {
    public void frear();
}

public class FreioComABS implements IComportamentoDeFreio {
    public void frear() {
        System.out.println("Freio com ABS aplicado");
    }
}

public class FreioSimples implements IComportamentoDeFreio {
    public void frear() {
        System.out.println("Freio simples aplicado");
    }
}

/* Cliente que pode usar os algoritmos acima de forma intercambiável */
public abstract class Carro {
    private IComportamentoDeFreio comportamentoDeFreio;

    public Carro(IComportamentoDeFreio comportamentoDeFreio) {
      this.comportamentoDeFreio = comportamentoDeFreio;
    }

    public void aplicarFreio() {
        comportamentoDeFreio.frear(); // note que usamos a interface!
    }

    public void setComportamentoDeFreio(IComportamentoDeFreio tipoDeFreio) {
        this.comportamentoDeFreio = tipoDeFreio; // podemos mudar livremente!
    }
}

public class SUV extends Carro {
    public SUV() {
        super(new FreioComABS());
    }
}

public class CarExample {
    public static void main(final String[] arguments) {
        Carro suvCar = new SUV();
        suvCar.frear(); // freio com abs

        suvCar.setBrakeBehavior( new FreioSimples() );
        suvCar.frear();    // freia, mas sem abs.
    }
}

Nesse exemplo, note que definimos uma interface comum, a qual um carro se acopla, podemos trocar a implementação dessa interface livremente, também ajuda no OCP.

Liskov Substitution Principle

Funções que utilizam ponteiros ou referências para classes base devem ser capazes de usar objetos de classes derivadas sem saber disso

Nesse caso, vamos começar com citações:

"Se um gato possui raça e patas, e um cachorro possui raça, patas e tipoDoPelo, logo Cachorro extends Gato? Pode parecer engraçado, mas é (...) herança por preguiça, por comodismo, porque vai dar uma ajudinha. A relação “é um” não se encaixa aqui, e vai nos gerar problemas."
Paulo Silveira, no artigo Como não aprender orientação a objetos: Herança (SILVEIRA, 2006)

O Princípio da Substituição de Liskov (LSP) estabelece uma diretriz fundamental : Ele afirma que objetos de classes derivadas ou subclasses devem poder ser usados no lugar de objetos da classe base ou superclasse sem quebrar o comportamento esperado do programa. Em outras palavras, uma classe derivada deve estender ou especializar o comportamento da classe base sem modificar seu contrato.

"A ideia intuitiva de um subtipo é aquela cujos objetos fornecem todo o comportamento de objetos de outro tipo (o supertipo) mais algo extra."
Data Abstraction and Hierarchy (LISKOV, 1988)

Imagine um exemplo em que temos uma classe base chamada Animal e classes derivadas, como Cachorro e Gato. O LSP nos orienta a garantir que qualquer código que funcione com objetos Animal também funcione corretamente com objetos Cachorro e Gato. Isso significa que as subclasses não devem introduzir comportamentos que contradigam as expectativas estabelecidas pela classe base. Ou seja, se todo animal implementa o método comer, classes derivadas desse Animal devem também incluir o método comer, que funciona como esperado. (Se seu animal não come, reveja suas abstrações, o próximo princípio, ISP, pode ser útil aqui!)

Favoreça composição sobre Herança

Essa é uma frase amplamente falada no meio da computação, algo que você já ouviu milhares de vezes, seja em artigos, livros como o Design Patterns, do GoF ou até mesmo vídeos no youtube, mas por quê?

Em vez de herdar comportamentos de uma classe base, prefira compor objetos que fornecem os comportamentos necessários. O princípio de design normalmente começa pela definição de interfaces que representam o comportamento que o sistema deve exibir, as classes recebem objetos dessas interfaces e fazem os comportamentos a partir daí

Benefícios

Favorecer a composição proporciona maior flexibilidade no design. É mais natural construir classes de domínio de negócios a partir de vários componentes do que tentar encontrar pontos em comum entre eles e criar uma árvore de herança. Por exemplo, um pedal de acelerador e um volante têm poucos traços em comum, mas são componentes vitais em um carro.

Além disso, a composição oferece um domínio de negócios mais estável, pois está menos sujeito às peculiaridades dos membros da família. Em outras palavras, é melhor compor o que um objeto pode fazer (tem-um) do que estender o que ele é (é-um).

💡 Linguagens como Go e Rust não possuem mecanismos de herança, e focam exclusivamente na composição de tipos a fim de evitar problemas com herança.

Drawbacks

“Composition is good until it is not” - O uso excessivo de composição pode levar a classes superlotadas e complexas, mas de maneira geral, se você mantiver : A divisão de responsabilidades, O acoplamento controlado, Uso de Design Patterns adequados, isso provavelmente não será um problema.

Interface Segregation Principle

“*Make fine grained interfaces that are client specific.”
”Clients should not be forced to depend upon interfaces that they do not use”

Uncle Bob*

O Interface Segregation Principle (ISP) basicamente nos orienta a escrever interfaces coesas, em que seus métodos conversem entre si e sempre sejam implementados.

Vamos a um exemplo:

interface Imposto {
    NotaFiscal geraNota();
    double imposto(double valorCheio);
}

Imagine que em algum momento da existência da sua aplicação, um imposto não gere nota fiscal, nesse caso, ele irá jogar uma exception? retornar nulo? É exatamente esse tipo de situação que o ISP quer que você evite passar, pois ambas as opções anteriores são ruins e configuram quebra de contrato.

Nesse caso anterior, temos uma interface não muito coesa, com dois comportamentos distintos (isso se dá pois um imposto nem sempre gera nota), nesse caso, o mais adequado seria dividi-la em duas interfaces distintas, como por exemplo:

interface Tributavel{
    double imposto(double valorCheio);
}

interface GeradorNF{
    NotaFiscal geraNota();
}

Com isso, podemos fazer com que nossas classes sejam construídas por composição de interfaces que às sirvam perfeitamente, como:

class ImpostoGeraNota implements Tributavel, GeradorNF{
    // os dois métodos aqui
}
class Imposto implements Tributavel{
    //  implementa imposto(double valorCheio)
}

Many client specific interfaces are better than one general purpose interface

Uncle Bob

Além disso, muitas vezes queremos apenas parte dos atributos ou comportamentos de uma classe, e

Se você tiver uma classe que tenha vários clientes, em vez de carregar a classe com todos os métodos de que os clientes precisam, crie interfaces específicas para cada cliente e implemente-as na classe.

Design Principles and Design Patterns (MARTIN, 2000)

Citação retirada da Referência da Caelum

Por que?

Mas Kauê, por quê é uma boa prática criarmos interfaces magras? Como disse anteriormente, a palavra chave é coesão, a coesão é o elemento chave que garante a estabilidade de nossas interfaces, e se essa interface realmente precisar ser mudada, apenas os membros que implementam ela terão sua implementação alterada. No final das contas, o ISP é sobre avaliarmos a coesão das nossas interfaces,

Lembre-se também que devemos sempre nos acoplar a membros os mais estáveis possíveis! Nesse caso, tanto Tributavel quanto GeradorNF são mais interfaces coesas e estáveis.

“Classes que dependem de interfaces leves sofrem menos com mudanças em outros pontos do sistema. Novamente, elas são pequenas, portanto, têm poucas razões para mudar.” - Aniche, M. OOP E SOLID para Ninjas.

Dependency Inversion Principle

Depend upon Abstractions. Do not depend upon concretions. - Design Principles and Design Patterns, Bob Martin.

Aqui, vamos começar com conceitos bem fundamentados dentro da computação

“Depender de abstrações e não de implementações” - Bob Martin
”Programe voltado à interface, não à implementação” - Design Patterns, GoF

Mas o que isso significa? A ideia aqui é que abstrações e interfaces definem contratos estáveis para nossos sistemas, classes e comportamentos base do sistema, ou seja, não-voláteis, não devem ser impactados por implementação de módulos as quais elas dependem.

Sua classe que cuida do registro do usuário não deve depender da implementação que o envio de email possui, você não deve ter imports de uma biblioteca específica dentro de uma classe que cuida de regras de negócio. Nesse caso, você deverá usar abstração, por exemplo, EnviadorEmail e usará algum método dela que encapsule detalhes de implementação

Vamos ver um exemplo bom:

public interface EnviadorEmail {
    void enviarEmail(String destinatario, String mensagem);
}

// em seu próprio arquivo:
public class RegistrarUsuario {
    private final EnviadorEmail enviadorEmail;

    public RegistrarUsuario (EnviadorEmail enviadorEmail) {
        this.enviadorEmail = enviadorEmail;
    }

    public void registrarUsuario(String nome, String email) {
        // Lógica para registrar o usuário

        // Envio de e-mail de boas-vindas
        String mensagem = "Bem-vindo, " + nome + "!";
        enviadorEmail.enviarEmail(email, mensagem);
    }
}

No código acima, podemos mudar a implementação do provedor de email e não precisaremos mexer na classe RegistrarUsuário, perfeito!

💡 Nesse caso em específico, gosto da abordagem de eventos, onde o enviador de email que diz estar ouvindo eventos de cadastro, mudança de senha e/ou emissão de nota fiscal. Mas é apenas uma ressalva :)

Um pouco mais concreto:

Vamos dar algumas definições que podem ajudar a você seguir como guideline para garantir que seu código está desacoplado

Módulos de Alto Nível: São módulos que implementam regras de negócio, devem ser reutilizáveis, estáveis e inafetados por mudanças em módulos de baixo nível.

Módulos de Baixo Nível: São módulos que dizem respeito à detalhes de implementação, muitas vezes, agem como utilitários para módulos de alto nível, mas devem ser utilizados através de uma barreira de abstração sempre que fizer sentido

💡 Nem toda abstração é necessária, nem todo acoplamento é ruim. Não faz sentido abstrairmos classes estáveis da linguagem que estamos utilizando, como por exemplo, a classe String em Java.

Portanto, nossa “”regra”” é:

Módulos de Alto nível não devem depender explicitamente de módulos de baixo nível, e sim de abstrações.

E de onde vem o nome de “Inversão de Dependência”?

No exemplo acima é claro, RegistrarUsuário, uma classe de alto nível, depende do Enviador de Email, que utiliza a dependência do AWS SES, no final das contas, RegistrarUsuário também está acoplado ao SES.

Nesse caso, note que as dependências foram invertidas.

Nem toda interface é de alto nível

A linguagem Java está cheia de interfaces e abstrações, mas muitas vezes essas abstrações atuam diretamente sobre detalhes de implementação, como java.sql.Connection do JDBC, elas são interfaces para mecanismos de entrega, detalhes técnicos e uma classe que depende delas, não necessariamente segue o dip, mas isso não é um problema, pois essas interfaces são estáveis

Dicas gerais

Não precisamos implementar e criar uma dependência diretamente com a classe EnviadorEmailX ou EnviadorEmailY, nesse caso, podemos usar o design pattern Factory e abstrair essa dependência, podemos fazer isso dentro da própria interface com java.

public interface EnviadorEmail {
    void enviarEmail(String destinatario, String mensagem);

    static EnviadorEmail criarEnviadorEmailPadrao() {
        return new EnviadorEmailPadrao();
    }

    static EnviadorEmail criarEnviadorEmailAlternativo() {
        return new EnviadorEmailAlternativo();
    }
}
// Em outra classe
public class Main {
    public static void main(String[] args) {
        EnviadorEmail enviadorPadrao = EnviadorEmail.criarEnviadorEmailPadrao();
        EnviadorEmail enviadorAlternativo = EnviadorEmail.criarEnviadorEmailAlternativo();

        // Use as instâncias de EnviadorEmail conforme necessário
        enviadorPadrao.enviarEmail("destinatario@example.com", "Mensagem de teste");
        enviadorAlternativo.enviarEmail("outrodestinatario@example.com", "Outra mensagem de teste");
    }
}

Em java, se definirmos interfaces comuns para diversos provedores de notificação como enviadorMensagem, que ser para tanto enviadorEmail quanto enviadorSMS, podemos fazer com que o spring nos entregue uma lista com todos os Beans anotados com @Component que satisfaça essa interface (Podemos usar o applicationContext para isso), simplificando o código iterando pela lista e usando o seu método de enviar.

@Component
public class EnviadorEmail implements EnviadorMensagem {
    @Override
    public void enviarMensagem(String destinatario, String mensagem) {
            // abstraido :p
    }
}

@Component
public class EnviadorSMS implements EnviadorMensagem {
    // você já sabe
}

Importante!!

Obrigado pela leitura, espero que tenha sido útil, de verdade, tentei trazer exemplos de código e bastante citações, mas a maioria desse tipo de conteúdo é fonte dos livros da casa do código e caelum, mas de maneira mais enxuta e com minhas palavras, recomendo fortemente a compra dos dois livros abaixo.

Se encontrar erros ortográficos ou algo estranho, me envie uma mensagem ou comente aqui, arrumarei assim que possível. Não farei uma rigorosa verificação antes de postar aqui.

Referências

https://www.amazon.com.br/Design-Patterns-Object-Oriented-Addison-Wesley-Professional-ebook/dp/B000SEIBB8

https://en.wikipedia.org/wiki/Composition_over_inheritance

https://www.casadocodigo.com.br/products/livro-oo-solid

https://www.casadocodigo.com.br/products/livro-desbravando-solid

https://github.com/caelum/apostila-oo-avancado-em-java/blob/master/09-interface-segregation-principle.md

https://en.wikipedia.org/wiki/Strategy_pattern

https://refactoring.guru/design-patterns/command

Streams em JAVA: Tudo que você precisa saber

Kauê Gatto — Tue, 05 Sep 2023 22:54:17 +0000

Map, Filter, Reduce

Vamos começar com um exemplo?



* Given a list of people
* We need to compute the average of the age of those people
* For the people older than 20

Nesse caso, é meio claro, começamos com um objeto pessoa, mas trabalharemos / transformaremos o dado de uma maneira que consigamos a idade (map). O map pega um objeto, e mapeia para outro, geralmente de tipo diferente

Com isso, vamos filtrar o dado age, para que ele só compute a média de maiores de 20 anos. Isso é um filter. O filter literalmente filtra os dados, não os transforma (diferente de map) e decide se deve manter ou não o dado. 2.1. Filters em código recebem uma predicate como parâmetro, ela representa uma função que recebe um argumento e retorna um valor booleano.

Por fim, vamos calcular a média desse dado, já transformado de pessoas e filtado para que a idade seja >20. Essa operação avg é o reduce, nesse caso, vamos pensar nela a princípio como uma agregação (tipo min,max,count, etc).

Operação	Comportamento
Map	Transforma o dado, mudando seu tipo. Não muda o número de elementos.
Filter	Não transforma o dado, reduz (ou mantém igual) o número de elementos
Reduce	Combina os elementos em um resultado único. É uma operação terminal que produz um único valor com base em uma operação de redução, como soma, média ou máximo.

Por que usar Streams?



List<Person> people = ...;

int sum = 0;
int count = 0;
for (Person person: people) {
    if (person.getAge() > 20) {
        count++;
        sum += person.getAge();
    }
}
double average = 0d;

if(count > 0) {
    average = sum / count;
}

No exemplo acima, temos um código que descreve com detalhes o que deve ser feito para chegarmos em um resultado (o resultado do exemplo apresentado), e se mudarmos o algoritmo, precisamos mudar o código, mesmo que o algoritmo seja o mesmo. Não necessariamente precisa ser assim, em SQL, por exemplo, escreveríamos:



Select AVG(age) from People
Where People.age>20

Note que no exemplo acima, descrevemos ao código o que queremos que seja feito, as premissas, descrevemos o resultado, e não como o resultado deve ser computado.

Collection X Streams

Tudo certo, se o código faz parte de uma lista ou qualquer coleção, podemos tentar implementar assim:



List<Person> people = ...;
double average = 
people.map(person -> person.getAge())
    .filter(age — > age > 20)
    .average();

ERRADO! A API de collections não provê esse tipo de operações, o código acima não compila 😄!

Mas por que a API de Collections e Streams são separadas?

Imagine que essas operações são feitas em uma lista de 1.000.000 de pessoas! Portanto, após o primeiro map, você teria uma Lista com 1.000.000 de inteiros de idade (porque o map não reduziria o tamanho em si), acho que já deu para perceber que duplicar a collection vai ser altamente custoso para o processador e para a memória

💡 Um objeto de stream oferece operações de map / filter / reduce sem duplicação e com máxima eficiência!

Mas como isso funciona? Quando usamos pessoas.stream(), retornamos uma Stream<Pessoa>. Por definição, um objeto de stream não carrega dados, é grátis cria-lo.

A collection is an in-memory data structure to hold values and before we start using collection, all the values should have been populated. Whereas a java Stream is a data structure that is computed on-demand. Java Stream doesn’t store data, it operates on the source data structure (collection and array) and produce pipelined data that we can use and perform specific operations.

https://www.digitalocean.com/community/tutorials/java-8-stream

Operações Intermediárias X Finais

Streams atuam sobre coleções para realizar map / filter / reduce, operações intermediárias são operações sobre streams que retornam streams ( Stream<T> map() → Método de stream, retorna stream).

Operações finais são operações que retornam a coleção de novo, depois do processamento / pipelining acabar toList() é um exemplo

E como ficaria o código

Aqui está um exemplo de como ficaria o código.



List<Pessoa> pessoas = new ArrayList<>();

    pessoas.stream()
                 .map(...)
                 .filter(...)
                 .average();

💡 Importante: Você não pode processar a mesma stream duas vezes:



Stream personNames = personStream.map(Person::getName);
Stream emptyNames = personNames.filter( name -&gt; name.isEmpty())
Stream notEmptyNames = personNames.filter( name -&gt; !name.isEmpty())

Esse código quebrará, tendo em vista que estamos processando a mesma stream personNames duas vezes!



Stream personNames = personStream.map(Person::getName);
Stream personAges = personStream.map(Person::getAge);

Nesse caso, estamos aplicando o map para criar duas streams diferentes, não quebrará o código.



Stream emptyNames = personStream.map(Person::getName).filter(name -&gt; name.isEmpty());
Stream notEmptyNames = personStream.map(Person::getName).filter(name -&gt; !name.isEmpty());

Esse código, processando duas streams diferentes também funcionará

Por favor, não crie variáveis para trabalhar com streams, fiz por didática

FlatMapping

Flatmapping funciona para lidar com relações 1:N

Exemplo: Cidades, onde temos várias pessoas por cidade.

Suponha que queremos pegar todas as pessoas, independente de suas cidades. Nesse caso, nos preocupamos com a entidade relacionada, não com as cidades em si*. O flatmap faz isso, pega uma entidade Cidade e retorna para nós uma Stream<Pessoas>.*



List<City> cities = ...;

Function<City, Stream<Person>> flatMapper = 
    city -> city.getPeople().stream();

long count = 
    cities.stream()
    .flatMap(flatMapper) /*poderíamos colocar city -> city.getPeople().stream() direto*/
    .count()

💡 Uma operação de flatmap recebe um objeto e retorna uma stream de outros objetos



List words "Gomu","Gomu", "No", "Mi");

Stream streamStream =
words.stream()
.map(w -&gt; w.split("")) // Stream
.flatMap(Arrays::stream) ; // Stream

O flatmap funciona nesse caso, pois ao aplicar flatMap(Arrays::stream), você está dizendo ao Java para pegar cada array de caracteres da Stream e transformá-lo em uma stream de strings (Stream) usando o método estático Arrays.stream().

Streams a partir de RegEx



String sentence = "the quick brown fox jumps over the lazy dog";
String[] words = sentence. split(
Stream<String> wordsStream = Arrays.stream(words);
Ion count = wordsStream.count()

Ao fazermos dessa forma, criamos um array intermediário, perdemos o propósito de streams.

Podemos fazer:



Pattern pattern = Pattern.compile(" ");
long count = pattern.sp1itAsStream(sentence) . count();

Streams de outro tipo

Em java, existem interfaces de stream feitas para manipular certos primitivos mais adequadamente, um exemplo disso é a IntStream

IntStream

IntStream tende a ser mais eficiente em termos de espaço e desempenho quando você está trabalhando com valores inteiros primitivos, uma vez que evita a criação de objetos Integer.

A IntStream oferece operações especializadas para trabalhar com valores inteiros, como sum(), average(), range(), rangeClosed(), etc. Uma Stream<Integer> fornece operações de stream genéricas aplicáveis a objetos, mas é menos eficiente quando se trata de cálculos com tipos primitivos.

💡 Além do IntStream, também existem `LongStream`e `DoubleStream`(Além da `Stream`)

Refactoring → Exemplo com múltiplas tarefas ao mesmo tempo

Streams não são uma boa para realizarem múltiplas tarefas simultaneamente, portanto se temos um for loop que agrega valores à 3 variáveis diferentes, precisamos dividir em 3 for’s (repetidos) e trocar cada um deles por uma stream. Claro, isso diminui muito a performance, mas em um for com poucos elementos a serem iterados, será basicamente imperceptível.



public String statement() {

    double totalAmount = rentals.stream()
        .mapToDoub1e(this::computeRenta1Amount)
        .sum();
    int frequentRenterPoints = rentals.stream()
    .mapToInt (this::getFrequentRenterPoints)
    .sum();

    String statement = composeHeader();

    statement += rentals.stream()
    .map(this::computeStatementLine)
    .collect(Collectors.joining());

}

Reduções

Antes, ouvimos que redução era algo similar a uma agregação do SQL, vamos continuar com isso em mente, mas como isso funciona?

Vamos ter como exemplo a soma, a soma é uma uma implementação de BinaryOperator<Integer>, que pega dois elementos e os soma ( sum = (i1,i2) -> i1+i2;). Isso acontece com dois elementos por vez, associando os valores e depois somando com o outro.

Reduções de uma stream vazia

Mas e qual a redução de uma Stream vazia? A redução de uma Stream vazia é o seu elemento identidade (identity), um elemento identidade é um valor pré-definido que atua como ponto de partida em uma operação de redução. Em contextos de programação funcional, quando não há elementos para combinar na Stream, a operação de redução retorna o elemento identidade como resultado, garantindo que a operação seja definida e não cause exceções em casos de Stream vazia. Isso é especialmente útil para lidar com casos em que não há dados disponíveis para a operação específica, permitindo que o código se comporte de maneira previsível e segura.

Por exemplo, o identity de uma soma é 0, tendo em vista que o 0 não impactará no valor final, para múltiplicação, um.

Max, Min, Avg?

O "identity element" ou valor inicial para as operações de max, min e average em Streams do Java é um pouco diferente porque essas operações retornam um Optional, que pode ser vazio (caso a Stream esteja vazia) ou conter um valor, portanto, essas operações não tem valores identity.

Portanto, para acessar max, min e avg, você deve fazer algo do tipo:



Optional<Integer> max = numbers.stream().max(Integer::compareTo);
Optional<Integer> min = numbers.stream().min(Integer::compareTo);
OptionalDouble average = numbers.stream().mapToDouble(Integer::doubleValue).average();

    System.out.println("Max: " + max.orElse(null));
    System.out.println("Min: " + min.orElse(null));
    System.out.println("Average: " + average.orElse(Double.NaN));

Como podemos escrever nossas reductions?

Talvez você esteja se perguntando o porquê de entendermos também a fundamentação de identity elements, se ainda não ficou claro, vai ficar agora:

A operação reduce em Streams do Java tem dois parâmetros principais:

O valor inicial (identity element): Já foi explicado
Uma função de acumulação (accumulator function): Esta função é usada para combinar os elementos da Stream em um único resultado. A função deve ser uma expressão lambda ou um método de referência que aceite dois argumentos e retorne um resultado. Em soma, seria (a, b) -> a + b

💡 Se você não passar um identity correto, o resultado estará incorreto. Se sua stream não possuir um identity, você pode usar uma outra sobrecarga do método que não recebe o identity, mas retorna um Optional. Use-o somente se não possuir o identity…

Reduções em um container mutável

Reduções em um container mutável referem-se à aplicação de operações de redução, como soma, multiplicação, média, entre outras, a elementos armazenados em um contêiner que pode ser alterado durante o processo de redução. Um "container" neste contexto pode ser definido como uma estrutura de dados flexível que permite armazenar e modificar elementos de forma dinâmica (Lists, Maps, etc.). Portanto, podemos simplificar reduções em containers mutáveis como reduções em coleções.

Ao chamar .stream() em uma lista, você está criando uma Stream dos elementos contidos na lista. A Stream é uma sequência de elementos que pode ser processada de maneira funcional, mas não modifica a lista original. Quando você chama .max(), por exemplo, está solicitando o elemento máximo com base em algum critério da lista, mas a lista em si permanece a mesma.

Coletores!



List<Person> pessoasDaBaixada = new ArrayList() ;
pessoasDaBaixada.stream()
.filter(p -> p.getDDD().equals("013"))
.forEach(p -> pessoasDaBaixada.add(p));

Mas esse exemplo acima não é muito diferente do que já vimos, por que estamos focando nesse tipo de redução?

Para filtrar e coletar elementos em uma nova lista usando a API de Streams do Java, você deve usar um coletor adequado, como Collectors.toList()

Os coletores permitem que você capture os resultados das operações de redução em coleções ou outros tipos de dados concretos. Em outras palavras, eles transformam os elementos processados em uma Stream em uma coleção real que pode ser usada e manipulada posteriormente.



List<Person> pessoasDaBaixada = new ArrayList<>();

// Supondo que o número de DDD seja uma String
List<Person> pessoasComDDD13 = pessoasDaBaixada.stream()
    .filter(p -> "13".equals(p.getDDD()))
    .collect(Collectors.toList());
    //.toList() retornará uma lista imutável!

”O novo método Stream.toList() não produz nem uma lista não modificável nem é um atalho para collect(toUnmodifiableList()), porque toUnmodifiableList() **não aceita valores nulos. A implementação de Stream.toList() não é limitada pela interface Collector; portanto, Stream.toList() aloca menos memória. Isso a torna ideal para uso quando o tamanho da stream é conhecida antecipadamente.” Link para comentário no stackoverflow

Exemplos de Outros Coletores

Collectors.toSet(): Cria um conjunto a partir dos elementos da Stream, removendo duplicatas.
Collectors.toMap(keyMapper, valueMapper): Cria um map a partir dos elementos da Stream, usando funções de mapeamento para extrair chaves e valores.
Collectors.groupingBy(classifier): Agrupa elementos da Stream com base em um critério definido pela função de classificação.
Collectors.joining(delimiter): Concatena os elementos da Stream em uma única String usando um delimitador.
Collectors.summingInt() ou Collectors.summingLong(): Calcula a soma dos valores inteiros ou longos de elementos da Stream.

Exemplos de uso:



Map<Integer, List<Person>> pessoasPorIdade = pessoas.stream()
    .collect(Collectors.groupingBy(Person::getIdade));



List<Person> pessoas = Arrays.asList(
    new Person("Jorge", 25),
    new Person("Ben", 30),
    new Person("Jor", 35)
);

Map<String, Integer> mapNomeIdade = pessoas.stream()
    .collect(Collectors.toMap(Person::getNome, Person::getIdade));

💡 Não necessariamente precisamos de collectors para trabalhar com coleções, mas eles tornam a vida mais fácil, veja os dois exemplos anteriores:



// ex1

Map<Integer, List<Person>> pessoasPorIdade = new HashMap<>();

pessoas.forEach(person -> {

    Integer idade = person.getIdade();

    List<Person> pessoasComIdade = pessoasPorIdade.get(idade);

    if (pessoasComIdade == null) {

        pessoasComIdade = new ArrayList<>();

        pessoasPorIdade.put(idade, pessoasComIdade);

    }

    pessoasComIdade.add(person);

});

// ex2

Map<String, Integer> mapNomeIdade = new HashMap<>();

pessoas.stream().forEach(person -> mapNomeIdade.put(person.getNome(), person.getIdade()));

Pincelando: Streams Paralelas

À medida que exploramos as reductions e operações terminais, é crucial considerar o potencial das streams paralelas em Java, mas o que são? 🤔

Streams paralelas oferecem a capacidade de executar operações em paralelo, aproveitando múltiplos núcleos da CPU, o que melhora muito o desempenho da stream.

Apesar disso, vale dizer que operações em paralelo nem sempre podem ser consideradas em uma stream, suponha que você esteja calculando uma média com uma reduction, para calcularmos a média, precisamos primeiro somar os elementos, e então dividirmos, se somarmos e depois dividirmos partes distintas, isso trará um resultado incorreto, isso significa que a média é uma operação não associativa!

Operações Associativas

São operações em que a ordem em que os elementos são combinados não afeta o resultado. Exemplos comuns de operações associativas incluem soma e multiplicação.



List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);

// Cálculo da soma em uma stream paralela

int sum = numbers.parallelStream().reduce(0, Integer::sum);

Esse parágrafo tem como objetivo apenas introduzir e notificar a existência de streams paralelas, procure saber mais sobre elas!

Operações Não-Associativas

São o oposto!

Conclusão e Agradecimento

Obrigado pela leitura, espero que tenha sido produtiva e que você tenha todo o conhecimento necessário para conseguir dar seus próprios passos e construir streams funcionais e avançadas, caso necessário.

Referências

https://app.pluralsight.com/library/courses/692a1310-42db-4f3c-a33b-208a55b7bd84/table-of-contents

https://www.digitalocean.com/community/tutorials/java-8-stream

Maratona Java Virado no Jiraya

https://acervolima.com/coletores-java/