Forem: Wagner Negrão 👨‍🔧

Desacoplamento e Reatividade: Implementando o Design Pattern Observer com Spring Events

Wagner Negrão 👨‍🔧 — Tue, 17 Feb 2026 19:05:31 +0000

Em nossa jornada como desenvolvedores, frequentemente nos deparamos com a necessidade de orquestrar múltiplas ações a partir de um único evento central. Este é um desafio clássico que, se não for abordado corretamente, pode levar a um alto acoplamento e à temida "bola de lama" de código.

Neste post, vou compartilhar um cenário real de pagamento em um sistema e como o Design Pattern Observer, implementado através do Spring Event, se mostrou a solução elegante e robusta para garantir a reatividade e o desacoplamento de nosso fluxo. O Problema: Acionamento Múltiplo e Consistência.

Imagine o fluxo de processamento de um pagamento. A etapa final retorna um status central: Success, Fail ou Pending. Com a chegada dessa resposta, várias operações de follow-up precisam ser disparadas simultaneamente e de forma independente:

Notificação: Enviar um e-mail de confirmação ou erro ao cliente.
Integração: Gerar um push de notificação para uma fila externa (ex: para processamento em um serviço de Notificações Assíncronas).

O problema aqui não é apenas executar as ações, mas fazê-lo sem que a classe de PaymentService precise conhecer ou ser responsável por cada uma delas. A solução deve permitir adicionar novas ações no futuro sem alterar o código principal do pagamento, seguindo o princípio Open/Closed do SOLID. A Solução Arquitetural escolhido foi o Padrão Observer.

O Observer é um padrão comportamental que define uma dependência um para muitos entre objetos.

Um objeto (Subject ou Publisher) notifica todos os seus dependentes (Observers ou Subscribers) sobre qualquer alteração de estado.
Os dependentes são notificados e reagem à mudança, sem que o Subject saiba a identidade ou o propósito específico de cada um.

Identificamos que essa era a abstração perfeita para o nosso cenário.

Implementação Prática com Spring Events.

No ecossistema Spring Boot, a maneira mais idiomática e gerenciada de implementar o padrão Observer é através dos Spring Events. O framework assume a responsabilidade pela orquestração do padrão, simplificando drasticamente a implementação.

Para isso, definimos três componentes principais:

1. O Evento (ApplicationEvent):

Criamos o objeto que encapsula o dado a ser transmitido. Ele deve estender de ApplicationEvent, permitindo que o Spring Context o monitore.

public class PaymentEvent extends ApplicationEvent {
    private final PaymentResponse paymentResponse;
    public PaymentEvent(Object source, PaymentResponse paymentResponse) {
        super(source);
        this.paymentResponse = paymentResponse;
    }

    public PaymentResponse getPaymentResponse() {
        return paymentResponse;
    }
}

2. O Publicador (ApplicationEventPublisher):

O serviço que conclui o pagamento (nosso Subject) passa a ter uma dependência no publisher do Spring. É ele quem realiza o disparo no momento crucial do fluxo.

@Service
public class PaymentService {
    private ApplicationEventPublisher publisher;

    public PaymentService(ApplicationEventPublisher publisher) {
        this.publisher = publisher;
    }

    public void processPayment(PaymentResponse response) {
        publisher.publishEvent(new PaymentEvent(this, response));
    }
}

3. Os Listeners (Os Observers):

As classes de NotificationListener e EmailListener se tornam os nossos observadores. Utilizaremos duas anotações poderosas para o desacoplamento:

@EventListener: Marca o método como um ouvinte para o tipo de evento específico.
@async: Crucial para a performance. Garante que o Listener será executado em uma thread separada, liberando a thread principal do request de pagamento para finalizar rapidamente.

@Component
@Slf4j
public class EmailListener {
    @Async
    @EventListener
    public void handlePayment(PaymentEvent event) {
        log.info("Email send for payment: " + event.getPaymentResponse().paymentStatus());
    }
}

@Component
@Slf4j
public class NotificationListener {
    @Async
    @EventListener
    public void handlePayment(PaymentEvent event) {
        log.info("Notification send for payment: " + event.getPaymentResponse().paymentStatus());
    }
}

Controle Fino e Consistência Transacional

Para um projeto não basta apenas que funcione; precisamos de controle e garantia de consistência. O Spring Event oferece recursos para isso.

Ordem de Execução

Se, em um cenário futuro, for necessário que a Notificação seja processada antes do E-mail, podemos forçar a ordem utilizando a anotação @Order(1) (ou qualquer número) no método listener. O Spring respeitará a ordem de prioridade definida. O Listener Transacional @TransactionalEventListener faz parte de um dos maiores desafios em sistemas distribuídos é garantir que as ações reativas (como enviar um e-mail) só ocorram se a transação do banco de dados (o commit do pagamento) for bem-sucedida.

É aqui que entra o @TransactionalEventListener. Ao utilizá-lo com phase = TransactionPhase.AFTER_COMMIT, garantimos queo listener só será disparado após a transação de banco de dados ser efetivamente comitada. Se o commit falhar (um rollback), o evento nunca será disparado, prevenindo o envio de e-mails sobre pagamentos que nunca foram registrados no banco.

@Component
@Slf4j
public class OtherListener {
    @Async
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void handlePaymentSuccess(PaymentSuccessEvent event) {
        log.info("Other notification: {}", event.getPayment().getUserEmail());
        // Ex: push SMS
    }
}

Considerações de Escalabilidade e Resiliência

Embora o Spring Event seja uma ferramenta excelente para o desacoplamento dentro do mesmo serviço (monolito ou microsserviço), há ressalvas importantes que se deve considerar.

Gerenciamento de Threads Assíncronas

O uso de @async consome threads do pool interno do Spring. Sem a configuração correta de um pool dedicado (AsyncConfig), podemos ter um cenário de Thread Pool Exhaustion.

Risco: Estratégias de retry mal planejadas ou listeners que demoram muito para executar podem exaurir o pool, levando a thread locks e, em casos extremos, à queda do sistema.
Mitigação: É fundamental definir um AsyncConfig com limites controlados de threads e um RejectedExecutionHandler adequado para lidar com a sobrecarga.

@Configuration
@EnableAsync
public class AsyncConfig implements AsyncConfigurer {

    @Override
    @Bean(name = "taskExecutor")  // Name for @Async("taskExecutor")
    public Executor getAsyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();

        // Limited pool: 4 always-living threads
        executor.setCorePoolSize(4);
        executor.setMaxPoolSize(8);  // Max 8 threads under load
        // LIMITED QUEUE: avoids overload
        executor.setQueueCapacity(25);  // Maximum 25 tasks in the queue
        // Prefix for debugging (see logs: Async-1, Async-2...)
        executor.setThreadNamePrefix("Payment-Async-");
        // Handler: rejects extra tasks (not an infinite queue)
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        // Shutdown: wait for tasks to finish
        executor.setWaitForTasksToCompleteOnShutdown(true);
        executor.setAwaitTerminationSeconds(60);
        executor.initialize();
        return executor;
    }
}

Limitações de Volume e Arquitetura

É crucial entender que o Spring Event é uma solução de evento local (In-Process Messaging). Isso significa que:

Ele tem um limite natural de escalabilidade. Em cenários de altíssimo volume (como acima de 200K requisições/minuto), a sobrecarga do thread pool se torna um gargalo.
Ele não resolve problemas de comunicação entre microsserviços (arquiteturas distribuídas).

Nesses casos de extrema escala ou arquitetura distribuída, a solução ideal migra para o uso de um Message Broker dedicado (como Kafka, RabbitMQ ou SQS).

Conclusão

O Spring Event é uma ferramenta de produtividade fantástica que permite implementar o poderoso Design Pattern Observer de forma simples e gerenciável. Ele é ideal para desacoplar ações secundárias e dar reatividade aos fluxos dentro de um mesmo serviço. No entanto, é importante ir além do uso básico, configurando corretamente os aspectos assíncronos e entendendo os limites de sua escalabilidade e a diferença entre eventos locais e arquiteturas de mensageria distribuída.

Com essa estrutura e esses cuidados, seu sistema estará mais robusto, escalável (dentro do contexto do serviço) e, o mais importante, fácil de manter e evoluir.

Até a próxima!

Como o Strategy Pattern simplificou a lógica de pagamentos do meu sistema Spring

Wagner Negrão 👨‍🔧 — Wed, 04 Feb 2026 01:40:01 +0000

Neste post, vou mergulhar em um design pattern que resolveu um desafio prático de arquitetura de software: a necessidade de aplicar um padrão de execução específico para processar uma requisição, dependendo do tipo de pagamento retornado em um response. Para cada modalidade de pagamento, como cartão de crédito, PayPal, etc. Uma ação distinta precisava ser executada.

A solução que se destacou foi a aplicação do Padrão de Projeto Strategy. Ele se mostrou ideal porque permite isolar cada lógica de processamento em sua própria classe (sua "estratégia"), tornando o código mais limpo, claro para manutenção e, crucialmente, altamente escalável para o futuro, caso novos métodos de pagamento sejam adicionados.

Lembrete: o código que apresento é uma simplificação do ambiente real, mas o foco está na essência da solução arquitetônica.

1. Definindo a Interface de Processamento

O primeiro passo foi estabelecer o contrato comum para todas as estratégias de pagamento. Criei a interface PaymentProcessor, que define o método que será implementado por cada classe de processamento especializada.

public interface PaymentProcessor {
    boolean process(final PaymentResponse request);
}

2. O Serviço que Gerencia as Estratégias

Em seguida, criei a classe PaymentService, o coração da nossa solução. Sua responsabilidade é mapear e gerenciar todas as implementações da interface PaymentProcessor. Isso nos permite identificar qual classe é responsável por cada tipo de execução. No exemplo, iniciei com as estratégias Paypal e Credit Card. Para garantir a qualidade e um controle rigoroso dos tipos suportados, utilizei um Enum chamado PaymentType, facilitando a adição ou remoção de novas modalidades, como um futuro Debit Card.

@Service
public class PaymentService {
    private Map<PaymentType, PaymentProcessor> processors;

    public PaymentService(@Qualifier("paypal") PaymentProcessor paypal,
                          @Qualifier("credit_card") PaymentProcessor credit) {
        processors = Map.of(PaymentType.PAYPAL, paypal, PaymentType.CREDIT_CARD, credit);
    }

    public boolean process(String type, PaymentResponse request) {
        PaymentType paymentType = PaymentType.valueOf(type.toUpperCase());
        PaymentProcessor processor = processors.get(paymentType);
        if (Objects.isNull(processor)) {
            throw new IllegalArgumentException("Type not supported: " + type);
        }
        return processor.process(request);
    }
}

public enum PaymentType {
    PAYPAL, CREDIT_CARD, DEBIT_CARD
}

3. Implementando as Estratégias de Pagamento

Agora, criamos as classes PayPalProcessor e CreditCardProcessor. Ambas implementam a interface PaymentProcessor. Utilizando o framework Spring Boot, estas classes são anotadas para que, ao iniciar a aplicação, o framework possa identificá-las e gerenciar seus beans corretamente, injetando-os no PaymentService. Dessa forma, o PaymentService terá todas as estratégias mapeadas e prontas para uso.

@Component
@Qualifier("paypal")
public class PayPalProcessor implements PaymentProcessor{
    @Override
    public boolean process(PaymentResponse request) {
        System.out.println("✅ PayPal processed!");
        return true;
    }
}

@Component
@Qualifier("credit_card")
public class CreditCardProcessor implements PaymentProcessor{
    @Override
    public boolean process(PaymentResponse request) {
        System.out.println("✅ credit card processed!");
        return true;
    }
}

4. A Execução e o Fim dos IFs

Chegamos ao ponto crucial, a execução. Recebemos o PaymentResponse (que simula o retorno de outras APIs), e seu campo paymentType informa qual tipo de pagamento estamos lidando. O PaymentService entra em ação, processando a informação diretamente. A grande vitória aqui é a eliminação da necessidade de blocos condicionais (IF/ELSE ou SWITCH/CASE) para verificar o tipo de pagamento.

Graças à gestão de beans do Spring Boot, no momento da requisição, o PaymentService simplesmente solicita a estratégia (get) para o paymentType informado e executa o método correto. Essa abordagem não apenas melhora a manutenibilidade, mas também busca garantir o safety mode, prevenindo erros comuns em Java, como o temido NullPointerException.

ORM, JPA, Hibernate, JDBC, JPQL, DDL, DML e DQL: descomplicando a sopa de letrinhas do Java

Wagner Negrão 👨‍🔧 — Thu, 15 Jan 2026 11:13:25 +0000

Neste post, vamos destrinchar essa famosa “sopa de letrinhas” do mundo Java: ORM, JPA, Hibernate, JDBC, JPQL, DDL, DML e DQL. A ideia é explicar, de forma direta, o que cada sigla significa, como se relacionam entre si e onde entram no dia a dia de desenvolvimento.

Começando por ORM (Object-Relational Mapping): trata-se de um conceito que define como converter dados entre o modelo de objetos de uma linguagem orientada a objetos e o modelo relacional de um banco de dados. Em outras palavras, o ORM faz a ponte entre classes e tabelas. ORM não é algo exclusivo de Java: cada linguagem costuma ter seus próprios frameworks, como Java (Hibernate, EclipseLink), .NET (Entity Framework) e Python (SQLAlchemy).

Já a JPA (Java Persistence API) é a especificação padrão de como fazer ORM no ecossistema Java. Ela define a “contrato”, como mapear entidades, como funcionam operações de persistência, consultas, transações e assim por diante. Para que isso tudo rode de verdade, precisamos de uma implementação dessa especificação, como o Hibernate, que é o framework concreto responsável por executar o que a especificação define como se fosse a relação entre uma interface e sua implementação. Um ponto importante: hoje o nome oficial da especificação é Jakarta Persistence; o termo “JPA” ficou associado às versões mantidas pela Oracle e não é mais usado para as versões open da comunidade.

Até aqui, podemos resumir assim: ORM é o conceito; Jakarta Persistence (antiga JPA) é a especificação de ORM no mundo Java; e o Hibernate é o framework ORM que implementa essa especificação.

Agora, entrando em JDBC (Java Database Connectivity). O JDBC é a API de baixo nível do Java para conversar com o banco de dados: abrir conexão, preparar e executar SQL, tratar resultados, entre outras operações. Todo framework ORM em Java usa JDBC por baixo; o ORM não substitui o JDBC, ele o abstrai. Com JDBC puro, é possível controlar diretamente as conexões e os comandos SQL, mas isso também aumenta o risco de problemas como múltiplas conexões abertas sem necessidade, falhas de tratamento de erros ou vulnerabilidades como SQL injection, se o código não for bem cuidado. Por isso, o uso de JDBC puro costuma ficar restrito a cenários em que controle fino e desempenho máximo são essenciais.

Com isso em mente, fica mais fácil visualizar a pilha: quando usamos Jakarta Persistence com o Hibernate como implementação, o framework cuida das entidades e consultas em nível de objeto e, por baixo dos panos, utiliza JDBC para se conectar ao banco de dados e executar os comandos SQL.

Falando agora das ações no banco de dados, entramos nas siglas DDL, DML e DQL.

DDL (Data Definition Language) é o conjunto de comandos usados para definir ou alterar estruturas, como CREATE TABLE e ALTER TABLE.
DML (Data Manipulation Language) cuida da manipulação de dados, com comandos como INSERT, UPDATE e DELETE.
DQL (Data Query Language) é focada em consultas de dados, basicamente o SELECT.

No cotidiano de uma aplicação, usamos essas linguagens o tempo todo, mesmo sem perceber. Por exemplo: ao subir uma aplicação que cria as tabelas no banco, estamos executando DDL. Quando a aplicação recebe uma requisição POST e grava os dados em uma tabela, isso envolve DML. E quando chega um GET para buscar informações, é executada uma consulta DQL. Essas coisas acontecem automaticamente via framework, mas é importante saber o nome e o papel de cada tipo de comando.

Por fim, temos o JPQL (Java Persistence Query Language). Ela é a linguagem de consultas orientadas a objetos definida pela especificação JPA/Jakarta Persistence. Em vez de trabalhar diretamente com tabelas e colunas, o JPQL opera sobre classes e atributos, o que ajuda a abstrair o banco de dados. Quando usamos Jakarta Persistence em conjunto com o Hibernate, as consultas JPQL são traduzidas para SQL (normalmente DQL) e executadas via JDBC no banco de dados.

A tabela foi criada para que seja mais claro e objetivo a função de cada item que foi mencionado.

Conceito/Ferramenta	Tipo/nível	Papel principal
ORM	Conceito/técnica	Mapear objetos, tabelas, abstraindo SQL
Jakarta Persistence (JPA)	Especificação Java	Define API padrão de ORM em Java.
Hibernate	Implementação ORM	Implementa Jakarta Persistence + features extras
JDBC	API de baixo nível	Conectividade e execução de SQL no Java
DDL	Categoria de comandos SQL	Define estrutura (CREATE, ALTER, DROP)
DML	Categoria de comandos SQL	Manipula dados (INSERT, UPDATE, DELETE)
DQL	Categoria de comandos SQL	Consulta dados (SELECT)
JPQL	Linguagem de consulta JPA	Consulta entidades em vez de tabelas

Para tornar mais claro o entendimento no cotidiano do trabalho foi criado um fluxo para melhor entendimento em cada etapa da relação do Java com banco de dados.

Modularização em Arquitetura de Software: Guia Prático para Desenvolvedores

Wagner Negrão 👨‍🔧 — Tue, 06 Jan 2026 11:31:26 +0000

Introdução à modularização

Modularização é a prática de dividir um sistema em módulos: grupos de código que resolvem um problema específico e expõem interfaces bem definidas. Em Java, isso costuma aparecer como pacotes, JARs e, a partir do Java 9, o sistema de módulos nativo; em .NET, como assemblies e namespaces.

A motivação é simples: em um monolito grande, qualquer mudança pode ter efeitos imprevisíveis, porque tudo está misturado. Ao modularizar, cada parte do sistema fica mais fácil de entender, testar, reaproveitar e implantar de forma isolada.

Imagine um e-commerce com autenticação, pedidos e pagamentos. Em um monolito desorganizado, uma alteração no login pode quebrar o fluxo de pedidos. Já em um sistema modular, há módulos separados para autenticação, pedidos e pagamentos, com contratos claros entre eles. Isso permite que cada módulo evolua em ritmos diferentes e, em arquiteturas com microsserviços, cada parte pode ser escalada ou atualizada de forma independente, muitas vezes usando mensageria como Kafka.

Coesão: foco em uma responsabilidade

Coesão mede quão bem as partes internas de um módulo “puxam para o mesmo lado”. Um módulo com alta coesão tem elementos (métodos, classes) todos voltados para um mesmo propósito. Já um módulo com baixa coesão mistura funcionalidades que não têm relação direta.

Na prática, classes e módulos de alta coesão são mais fáceis de testar, entender e refatorar, porque fazem “uma coisa bem feita”. Uma forma comum de quantificar coesão em nível de classe é a métrica LCOM (Lack of Cohesion of Methods), que, em essência, verifica quantos métodos não compartilham atributos. LCOM alto indica baixa coesão, sugerindo que a classe talvez deva ser dividida.

Alguns tipos de coesão, do melhor para o pior, ajudam a avaliar o design:

Funcional: tudo contribui para uma única tarefa.
Exemplo: um módulo CalculoFrete com métodos focados apenas em regras de frete (por CEP, por peso, por transportadora).

Sequencial/Comunicacional: operações que trabalham sobre os mesmos dados em uma sequência lógica.
Exemplo: lerPedido() → calcularFrete() → enviarConfirmacao() usando o mesmo objeto Pedido.

Procedural/Temporal: elementos ligados pela ordem/timing de execução (como rotinas de inicialização).

Lógica: métodos agrupados por “tipo de operação”, mas não necessariamente por um objetivo de negócio (por exemplo, vários utilitários de string em uma mesma classe).

Coincidente: elementos sem relação clara, apenas colocados juntos. Esse é o tipo de coesão mais fraco e deve ser evitado.

Exemplo simplificado em Java:

// Baixa coesão: mistura responsabilidades de domínio, cálculo e infraestrutura
public class PedidoController {
    public void criarPedido() { /* lógica de criação / persistência */ }
    public void calcularFrete() { /* regra de negócio de frete */ }
    public void enviarEmail() { /* integração com e-mail */ }  // responsabilidades distintas
}

// Alta coesão: cada classe com foco em uma responsabilidade
@Service
public class CalculoFreteService {
    public double calcularPorCep(String cep, double peso) {
        return peso * 0.1 + (cep.startsWith("03") ? 5.0 : 10.0);
    }
}

Em um cenário de microsserviços, CalculoFreteService pode se tornar um serviço separado, consumindo eventos de um tópico Kafka (pedido-events) e cuidando apenas da parte de frete. Isso aumenta a coesão do serviço e torna suas dependências mais explícitas.

Acoplamento: dependência entre módulos

Se coesão fala sobre “o que está dentro”, acoplamento fala sobre “como módulos se relacionam entre si”. Acoplamento é o grau de dependência entre módulos, classes ou serviços: quanto mais um precisa conhecer detalhes internos do outro para funcionar, maior o acoplamento.

Um certo nível de acoplamento é inevitável: módulos precisam conversar. O problema é o acoplamento excessivo, que torna o sistema frágil: pequenas mudanças em um módulo obrigam alterações em vários outros.

Ca e Ce

Robert C. Martin propõe duas métricas de acoplamento entre módulos:

Ca (Afferent Coupling): quantos módulos dependem deste módulo (“quantos me usam”).

Ce (Efferent Coupling): de quantos módulos este módulo depende (“de quantos eu preciso para funcionar”).

Voltando ao fluxo Pedido → Pagamento → Notificação:

O módulo Pedido pode depender apenas de Pagamento (Ce = 1), enquanto o frontend depende de Pedido (Ca = 1).
O módulo Pagamento depende de Notificação e de um gateway externo (Ce = 2), enquanto Pedido e talvez um serviço de cobrança recorrente dependem dele (Ca = 2).
O módulo Notificação depende de provedores externos (Ce baixo) e é usado por vários módulos (Ca alto), como Pedido, Pagamento e Cadastro.

Mesmo sem calcular números exatos, o exercício de mapear “quem chama quem” já ajuda a visualizar onde o acoplamento está concentrado.

Abstractness (A) e Instability (I)

Além de Ca e Ce, Martin define:

Abstractness (A): proporção de elementos abstratos (interfaces, classes abstratas) em relação ao total de classes do módulo, sendo A = numero de interfaces + classes abstratas / numero total de classes do modulo. Varia de 0 (totalmente concreto, muito “pé no chão”, pouco flexível) a 1 (totalmente abstrato).
Instability (I): quão “puxado” o módulo é por suas dependências externas. É calculado como I = Ce/(Ca+Ce), variando de 0 (estável, muitos dependem de mim, dependo de poucos) a 1 (instável, várias dependências e muito flexível, mas talvez pouco utilizável sozinho).

Com isso, surge a ideia da Main Sequence: módulos saudáveis tendem a ficar próximos da linha em que A+I≈1.

Módulos muito concretos e muito estáveis (A baixo, I baixo) tendem a ficar na “Zona de Dor”: são centrais, muita gente depende deles e qualquer mudança é arriscada.
Módulos muito abstratos e pouco usados (A alto, I baixo) caem na “Zona de Uselessness”: abstrações sofisticadas, mas sem uso real.

Exemplo concreto com o fluxo Pedido → Pagamento → Notificação

Em um design inicial muito acoplado, o código pode ser assim:

@Service
public class PedidoService {
    private final EmailServiceImpl email = new EmailServiceImpl(); // depende da implementação concreta
}

Aqui, PedidoService está fortemente acoplado à implementação específica de e-mail.

Aplicando o Princípio da Inversão de Dependência (DIP), o módulo passa a depender de uma abstração:

public interface NotificacaoService {
    void enviar(String mensagem);
}

@Service
public class PedidoService {
    private final NotificacaoService notificacao;

    public PedidoService(NotificacaoService notificacao) {
        this.notificacao = notificacao;
    }
}

Com isso:

O Ce do módulo de pedidos deixa de apontar para a implementação concreta e passa a apontar para uma abstração.
O módulo de notificação pode ter múltiplas implementações (e-mail, SMS, push), aumentando o Abstractness (A) desse módulo sem aumentar tanto sua Instability (I), já que muitos módulos dependem da interface e poucos detalhes concretos são expostos.

Em uma arquitetura de microsserviços, o acoplamento pode ser reduzido ainda mais se o serviço de pedidos publicar um evento PedidoCriado em um broker (como Kafka) e o serviço de notificação consumir esse evento sem conhecer detalhes internos de Pedido. Assim, o acoplamento entre serviços é mais fraco (assíncrono e orientado a eventos), e cada serviço pode ser implantado e escalado de forma independente.

Connascence: dependências mais sutis

Enquanto acoplamento e coesão olham para dependências mais “macro”, connascence foca em dependências sutis entre elementos: situações em que mudar algo em um lugar exige mudar em outro lugar para que o sistema continue correto.

Existem vários tipos de connascence, mas alguns são especialmente práticos no dia a dia:

Connascence of Name (CoN): dois módulos dependem de usar o mesmo nome.
Exemplo: constantes de status (STATUS_OK = 0) usadas em vários serviços; se o valor ou o nome muda, todos os consumidores precisam ser atualizados.

Connascence of Type (CoT): dependência do tipo exato de um parâmetro ou retorno.
Exemplo: um serviço espera List e outro passa Set, quebrando a integração.

Connascence of Value (CoV): dependência de valores específicos.
Exemplo: IDs ou códigos de status duplicados em múltiplos serviços; alterar o significado de um valor em um lugar exige alteração em todos os outros.

Connascence of Execution/Timing (CoE/CoT): dependência da ordem de execução.
Exemplo: um produtor Kafka que não garante a ordem esperada de eventos pode causar inconsistências em serviços consumidores.

A orientação geral é:

Tentar manter connascence forte (por exemplo, dependência de valores e ordem de execução) confinada dentro de um módulo.

Expor nas fronteiras do sistema dependências mais fracas e estáveis, como tipos bem definidos (contratos) e nomes claros.

Um exemplo simples em Java:

// Connascence de valor: o ID é apenas um número que precisa bater com outro serviço
public class Pedido {
    private Long clienteId; // precisa "bater" com o ID usado em ClienteService
}

// Melhora: relação mais explícita
@Entity
public class Pedido {
    @ManyToOne
    private Cliente cliente; // referencia forte, reduz Connascence de valor entre serviços locais
}

Em sistemas distribuídos, técnicas como schemas de eventos (Avro, JSON Schema) e correlação por IDs bem definidos ajudam a controlar connascence entre serviços. Por exemplo, um correlationId compartilhado em uma saga facilita rastrear o fluxo sem obrigar cada serviço a conhecer detalhes internos das entidades dos outros.

Refatoração prática rumo à modularização

Aplicando coesão, acoplamento e connascence em um projeto real (por exemplo, um monolito Spring Boot), um caminho prático é:

Medir e observar:

Use ferramentas de análise estática para inspecionar coesão (LCOM) e acoplamento (Ca, Ce) de pacotes e módulos.
Identifique classes com LCOM alto e módulos com Ca/Ce desequilibrados.

Extrair fronteiras naturais:

Use conceitos de Domain-Driven Design (DDD) para encontrar bounded contexts (Pedidos, Pagamentos, Catálogo, Clientes).
Reorganize pacotes e módulos para refletir essas fronteiras de domínio.

*Reduzir acoplamento concreto: *

Introduza interfaces em pontos de integração (notificação, gateways de pagamento, repositórios).
Use injeção de dependência para depender de abstrações, não de implementações.

Controlar connascence entre serviços:

Use contratos explícitos (APIs, schemas de eventos) e evite compartilhamento implícito de valores “mágicos”. - Mantenha regras mais frágeis (valores específicos, ordem de eventos) encapsuladas dentro de um serviço.

Evoluir para microsserviços (quando fizer sentido):

A partir de um monolito modular bem definido, alguns módulos de alta coesão e responsabilidade clara podem ser extraídos como serviços independentes (por exemplo, PedidoService, PagamentoService, NotificacaoService).
A comunicação entre serviços tende a migrar de chamadas diretas para eventos assíncronos, reduzindo acoplamento temporal e facilitando deploys e escalabilidade independentes.

Essa abordagem permite que o sistema evolua sem grandes reescritas: mudanças ficam mais localizadas, a reutilização aumenta e o impacto de bugs diminui.

Referências:

Robert C. Martin – Agile Software Development: Principles, Patterns, and Practices.

Robert C. Martin – Clean Architecture.

Meilir Page-Jones – What Every Programmer Should Know About Object-Oriented Design.

Java Platform Module System.

Como Executar sua Aplicação Spring Boot no Kubernetes com Banco MySQL

Wagner Negrão 👨‍🔧 — Wed, 23 Jul 2025 11:56:11 +0000

Neste post, vamos aprender passo a passo como subir uma aplicação Spring Boot conectada a um banco de dados MySQL dentro do Kubernetes.

A ideia é ser didático e acessível, então, se você está começando agora, siga com calma cada etapa. Algumas instruções podem variar de acordo com o sistema operacional. Estou usando macOS, mas com pequenas adaptações, tudo funcionará em outros sistemas.

Pré-requisitos

Antes de começar, certifique-se de ter:

Docker instalado
Kubernetes instalado (Minikube, Docker Desktop ou outro)
Maven instalado (opcional, mas recomendado para build manual)
Postman ou cURL para testar a API

Se não tiver esses itens configurados ainda, recomendo procurar tutoriais específicos de instalação.

Etapa 1: Criando a Aplicação Spring Boot

Nossa aplicação será uma API REST simples para gerenciar pedidos (Order). Ela terá as operações básicas de criar e buscar pedidos. Vamos focar no essencial para que o projeto seja leve e fácil de entender.

Estrutura do Projeto

Vamos começar definindo a estrutura de dados para o nosso pedido.

@Getter
@Setter
@Entity
@Table(name = "orders")
public class Order {
   @Id
   @GeneratedValue
   private long id;
   private String productName;
   private int quantity;

   public Order(long id, String productName, int quantity) {
       this.id = id;
       this.productName = productName;
       this.quantity = quantity;
   }
}

O próximo passo é criar o repositório. Usaremos o JpaRepository, uma interface do Spring Data que já vem com operações básicas de CRUD.

public interface OrderRespository extends JpaRepository<Order, Long> {
}

Por fim, vamos criar o controller, que será responsável por expor os endpoints da API e interagir diretamente com o banco de dados por meio do repositório.

@RestController
@RequestMapping("/orders")
public class OrderController {

   private OrderRespository orderRespository;

   public OrderController(final OrderRespository orderRespository) {
       this.orderRespository = orderRespository;
   }


   @PostMapping
   public ResponseEntity<Order> create(@RequestBody Order order) {
       Order response = orderRespository.save(order);
       return ResponseEntity.ok(response);
   }


   @GetMapping("/{id}")
   public ResponseEntity<Order> getOrderById(@PathVariable Long id) {
       return orderRespository.findById(id)
               .map(ResponseEntity::ok)
               .orElse(ResponseEntity.notFound().build());
   }
}

Agora, vamos ver as configurações definidas no arquivo application.yaml, responsável por centralizar as propriedades da aplicação.


spring:
 datasource:
   url: jdbc:mysql://${DB_HOST}/${DB_NAME}?useSSL=false
   username: ${DB_USERNAME}
   password: ${DB_PASSWORD}
   driver-class-name: com.mysql.cj.jdbc.Driver
   hikari:
     initialization-fail-timeout: 0  # Disable initialization timeout


 jpa:
   database-platform: org.hibernate.dialect.MySQLDialect
   generate-ddl: true
   show-sql: true
   hibernate:
     ddl-auto: update
   properties:
     hibernate:
       format_sql: true

Algumas das informações acima estão parametrizadas com variáveis de ambiente. Vamos configurá-las mais adiante, mas você já pode deixá-las prontas no seu projeto.

Agora, vou compartilhar o conteúdo do pom.xml, que define as dependências e configurações do projeto. Assim, garantimos que todos estejam utilizando o mesmo ambiente e consigam reproduzir os resultados.

POM

Etapa 2 – Criando a imagem Docker

Agora, vou compartilhar o conteúdo do meu Dockerfile. É nele que definimos como a imagem Docker da aplicação será criada e executada.
Embora fosse possível usar uma versão mais leve, como a slim-buster, optei por manter a imagem padrão para facilitar o entendimento.


# configurando o maven
FROM maven:3.9.6-eclipse-temurin-17 AS build
WORKDIR /kubernetes
COPY . .
RUN mvn clean package -DskipTests


# configurando o java
FROM openjdk:17
EXPOSE 8080
WORKDIR /kubernetes
COPY --from=build /kubernetes/target/*.jar kubernetes-0.0.1-SNAPSHOT.jar
ENTRYPOINT ["java", "-jar", "/kubernetes/kubernetes-0.0.1-SNAPSHOT.jar"]

A imagem Docker foi dividida em duas partes: uma para compilar o código com o Maven e outra para executar a aplicação com Java. Essa separação é útil caso, no futuro, você queira automatizar o processo de build e deploy com ferramentas de CI/CD e Kubernetes.

Antes de continuar, verifique se sua estrutura de pastas está assim:

Etapa 3 – Criando os arquivos do Kubernetes

Agora vamos começar a criar os arquivos de configuração do Kubernetes. O primeiro será o Deployment, responsável por criar e gerenciar o Pod onde nossa API será executada.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: crud-deployment
spec:
 selector:
   matchLabels:
     app: crud-deployment
 replicas: 1
 template:
   metadata:
     labels:
       app: crud-deployment
   spec:
     containers:
     - name: crud-deployment
       image: springboot-k8s:1.0.8
       imagePullPolicy: IfNotPresent
       ports:
         - containerPort: 8080
       env:
         - name: DB_HOST
           valueFrom:
             configMapKeyRef:
               name: mysql-config
               key: dbHost
         - name: DB_NAME
           valueFrom:
             configMapKeyRef:
               name: mysql-config
               key: dbName
         - name: DB_USERNAME
           valueFrom:
             secretKeyRef:
               name: mysql-secret
               key: username
         - name: DB_PASSWORD
           valueFrom:
             secretKeyRef:
               name: mysql-secret
               key: password

Podemos observar que essa configuração define os seguintes parâmetros:


- name: crud-deployment
  image: springboot-k8s:1.0.8
  imagePullPolicy: IfNotPresent

No campo image, colocamos o nome da nossa imagem Docker, que será usada para criar o container no Pod. O imagePullPolicy: IfNotPresent garante que o Kubernetes só irá buscar a imagem no Docker Hub se ela ainda não estiver disponível localmente. Logo abaixo, temos as env, que são variáveis de ambiente. Elas se conectam com os dados do nosso application.yaml, mas ainda precisam ser configuradas.

A seguir, vamos criar o recurso Service, responsável por expor nossa aplicação na porta 8080.

apiVersion: v1
kind: Service
metadata:
 name: crud-svc
spec:
 selector:
   app: crud-deployment
 type: NodePort # or LoadBalancer validar o segundo caso
 ports:
   - port: 8080 # porta do serviço
     targetPort: 8080 # porta do container que sera exposta

Finalizamos a parte da API, então agora vamos configurar o banco de dados.
O primeiro passo é criar o Deployment, que define como o Kubernetes deve iniciar e manter o container do MySQL rodando corretamente.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: mysql-deployment
 labels:
   app: mysql
   tier: database
spec:
   selector:
       matchLabels:
         app: mysql
         tier: database
   replicas: 1
   template:
       metadata:
         labels: # Deve ser igual ao do servico e deployment
           app: mysql
           tier: database
       spec:
         containers:
           - image: mysql:5.7
             imagePullPolicy: IfNotPresent
             name: mysql
             args:
               - "--ignore-db-dir=lost+found"  # Ignore lost+found directory
             env:
               - name: MYSQL_ROOT_PASSWORD
                 valueFrom:
                   secretKeyRef:
                     name: mysql-secret
                     key: password
               - name: MYSQL_DATABASE
                 valueFrom:
                   configMapKeyRef:
                     name: mysql-config
                     key: dbName
             ports:
               - containerPort: 3306
                 name: mysql
             volumeMounts:
               - name: mysql-storage
                 mountPath: /var/lib/mysql
         volumes:
           - name: mysql-storage
             persistentVolumeClaim:
               claimName: mysql-pvc

Nesse arquivo, definimos as portas e os volumes necessários para o funcionamento do MySQL, além das variáveis de ambiente que representam as credenciais de acesso, que ainda serão configuradas.

Agora, vamos criar o Service, que irá expor o banco de dados na porta padrão 3306.

apiVersion: v1
kind: Service
metadata:
 name: mysql-svc
 labels:
   app: mysql
   tier: database
spec:
 ports:
   - port: 3306
     targetPort: 3306
     protocol: TCP
 selector:
   app: mysql
   tier: database
 clusterIP: None  # Use None for headless service if needed

Agora vamos configurar o PersistentVolumeClaim (PVC), que será responsável por garantir o armazenamento persistente dos dados do nosso banco de dados.


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: mysql-pvc
 labels:
   app: mysql
   tier: database
spec:
 accessModes:
   - ReadWriteOnce
 resources:
   requests:
     storage: 1Gi

Com a configuração do banco de dados finalizada, agora vamos criar os recursos que irão fornecer os valores para os parâmetros utilizados anteriormente.

Começaremos pelo ConfigMap, que será responsável por armazenar as configurações que não são sensíveis, como o nome do banco e o host.

apiVersion: v1
kind: ConfigMap
metadata:
 name: mysql-config
data:
 dbHost: mysql-svc
 dbName: javatest

Agora vamos configurar a Secret, que será usada para armazenar informações sensíveis, como usuário e senha do banco de dados.

No exemplo abaixo, os dados estão comentados, mas em um ambiente de produção, o ideal seria utilizar um serviço de gerenciamento de segredos, como o AWS Secrets Manager, HashiCorp Vault ou o próprio Sealed Secrets do Kubernetes.

apiVersion: v1
kind: Secret
metadata:
   name: mysql-secret
data:
   username: cm9vdA==  # encoded 'root'
   password: cm9vdA==  # encoded 'root'

Etapa 4 – Executando tudo

Vamos recapitular rapidamente o que foi feito até aqui:

Criamos os arquivos Deployment e Service da nossa API, que serão responsáveis por controlar a criação e exposição dos Pods da aplicação.
Em seguida, configuramos os arquivos de Deployment, Service e PersistentVolumeClaim para o banco de dados, garantindo seu funcionamento e armazenamento persistente.
Por fim, criamos o ConfigMap e a Secret, que armazenam respectivamente as variáveis de ambiente e informações sensíveis (como usuário e senha do banco).

Com tudo configurado, podemos agora executar os arquivos.

O primeiro passo é gerar a imagem da aplicação com base no Dockerfile.
Caso esteja usando o Minikube localmente, execute o seguinte comando no diretório onde está seu Dockerfile:

eval $(minikube docker-env)

Esse comando faz com que o terminal passe a usar o Docker interno do Minikube, tornando sua imagem visível para o cluster. Assim, ao executar os manifests do Kubernetes, o Minikube conseguirá encontrar e rodar sua imagem sem precisar baixá-la de um repositório externo.

Agora vamos executar o comando responsável por gerar a imagem Docker da nossa aplicação, utilizando o Dockerfile que criamos anteriormente. No terminal, dentro do diretório onde está localizado o Dockerfile, execute o seguinte comando:

docker build -t springboot-k8s:1.0.8 .

Neste exemplo, estou utilizando a versão 1.0.8 da imagem, mas você pode começar com a versão 1.0.0 e, futuramente, atualizar a tag no seu arquivo de Deployment do Kubernetes conforme necessário.

Para verificar se a imagem foi criada com sucesso, execute o seguinte comando no terminal:

docker images

Você deverá ver a imagem que acabou de ser gerada listada entre os resultados.

Agora, com tudo pronto, vamos aplicar os arquivos de configuração do Kubernetes para subir nossa aplicação.

 kubectl apply -f infra/

Caso o comando para aplicar todos os arquivos de uma vez não funcione corretamente — seja por erro de formatação em algum arquivo ou problema pontual —, você pode aplicar cada um manualmente com o seguinte comando:

kubectl apply -f nome-do-arquivo.yaml

Basta repetir esse comando para cada arquivo de configuração (como deployment.yaml, service.yaml, configmap.yaml, etc.), garantindo que todos os recursos sejam criados corretamente no cluster.

Se tudo ocorreu conforme o esperado, você poderá verificar os pods em execução com o seguinte comando:

kubectl get pods

Esse comando lista todos os pods ativos no cluster e seus respectivos status. Se tudo estiver certo, o status dos pods deve aparecer como Running.

Etapa 5 – Acessando a aplicação

Com tudo em execução, agora podemos fazer uma requisição para testar nossa API.

No entanto, se você estiver utilizando o Minikube, talvez precise criar um túnel para expor o serviço externamente, dependendo de como o ambiente foi configurado.

Para isso, execute o comando abaixo:

minikube service <nome-do-serviço>

Esse comando abrirá um endpoint acessível via navegador ou ferramentas como o Postman.

Se tiver dúvidas sobre qual nome usar, você pode listar todos os serviços disponíveis com:

minikube service list

A saída será parecida com isso:

Ao executar o comando:

minikube service <nome-do-serviço>

o Minikube criará automaticamente um túnel de conexão, abrindo uma URL no navegador (ou exibindo no terminal) que permite o acesso direto à sua API rodando dentro do cluster Kubernetes.

Esse túnel expõe a porta configurada no Service, facilitando testes locais sem a necessidade de configurar um Ingress ou LoadBalancer manualmente.

Etapa 6 – Testando via Postman

Agora que a aplicação está rodando e exposta corretamente, podemos fazer nossas requisições de teste usando o Postman (ou qualquer cliente HTTP de sua preferência).

Se você quiser remover os recursos criados (como Pods, Services, Deployments, etc.), basta executar o comando abaixo no diretório onde estão os seus arquivos de configuração:

kubectl delete -f infra/

Esse comando irá deletar todos os recursos definidos na pasta infra/, limpando o ambiente do cluster.

Espero que este post tenha sido claro e que você tenha conseguido executar todos os passos com sucesso.
Caso encontre algum problema ou tenha dúvidas durante o processo, deixe um comentário — ficarei feliz em tentar ajudar!

🚀 Próximo passo

No próximo post, vamos avançar mais um pouco, vamos configurar um Load Balancer e adicionar o Ingress à nossa estrutura Kubernetes, permitindo que diferentes aplicações se comuniquem entre si de forma controlada e organizada.

[Boost]

Wagner Negrão 👨‍🔧 — Sat, 05 Jul 2025 12:28:00 +0000

Wagner Negrão 👨‍🔧

Jul 5 '25

Entendendo o Design Pattern Pipeline na Prática

#java #designpatterns #productivity #programming

Comments

6 min read

Entendendo o Design Pattern Pipeline na Prática

Wagner Negrão 👨‍🔧 — Sat, 05 Jul 2025 12:27:07 +0000

Depois de um tempo sem escrever, volto com um tema muito útil para quem trabalha com processamento em etapas: o design pattern Pipeline.

O que é o Pipeline?

O padrão Pipeline é um tipo de padrão estrutural. Ele define uma sequência de etapas (ou estágios) para processar dados de forma modular e flexível.
É ideal para cenários em que você precisa executar várias validações ou transformações em uma ordem específica.

Um exemplo simples

Imagine um processo de compra online com as seguintes etapas:

Validar o pedido
Processar o pagamento
Enviar o produto

Cada etapa depende da anterior. Por isso, precisamos garantir que elas ocorram na ordem certa e o Pipeline ajuda exatamente nisso.
Ao separar cada etapa em blocos, conseguimos manter o código limpo, reutilizável e fácil de manter.

Implementando o Pipeline em Java

O padrão Pipeline pode ser implementado de várias formas. Vamos começar com uma abordagem usando interfaces.

1. Criando a entidade Order

public class Order {
    String orderId;
    double amount;
    String status;
// constructor
// getter
// setter
}

2. Criando a interface de processamento

Vamos criar a interface OrderProcessingStage, que define o método process, responsável por executar a lógica de cada etapa do pipeline.

public interface OrderProcessingStage {
    Order process(Order order);
}

3. Criando o pipeline

Em seguida, criamos a classe OrderProcessingPipeline, que possui dois métodos principais: addStage, para adicionar as etapas à lista de processamento, e execute, que percorre cada etapa executando sua lógica.

public class OrderProcessingPipeline {

    public List<OrderProcessingStage> stages = new ArrayList<>();

    public OrderProcessingPipeline addStages(OrderProcessingStage stage) {
        // Initialize the pipeline with stages
        if (stage != null) {
            stages.add(stage);
        }
        return this;
    }

    public Order execute(Order order) {
        // Execute each stage in the pipeline
        for (OrderProcessingStage stage : stages) {
            try {
                if ("invalid".equalsIgnoreCase(order.getStatus()) || "failed".equalsIgnoreCase(order.getStatus())) {
                    System.out.println("Order processing halted due to invalid status.");
                    break; // Stop processing if the order is invalid
                }

                if (stage.validate(order)) {
                    order = stage.process(order);
                }

            } catch (Exception e) {
                System.err.println("Error processing order at stage: " + stage.getClass().getSimpleName());
            }
        }
        // Return the final order after processing through all stages
        return order;
    }
}

4. Criando os estágios

Até aqui, já criamos a entidade Order, a interface OrderProcessingStage (que funciona como um contrato para as etapas) e a classe OrderProcessingPipeline, que gerencia o fluxo. Agora, vamos implementar.

4.1 Validação do pedido

public class ValidationStage implements OrderProcessingStage {
    @Override
    public Order process(Order order) {
        // Validate the order
        if (order.getAmount() <= 0) {
            order.setStatus("Invalid");
            System.out.println("Order validation failed: Amount must be greater than zero.");
            throw new IllegalArgumentException("Order amount must be greater than zero.");
        }

        order.setStatus("Validated");
        System.out.println("Order validation passed: " + order);

        // If validation passes, return the order for the next stage
        return order;
    }
}

4.1 Pagamento

public class PaymentStage implements OrderProcessingStage {
    @Override
    public Order process(Order order) {
        // Simulate payment processing
        if ("Invalid".equalsIgnoreCase(order.getStatus())) {
            order.setStatus("failed");
            System.out.println("Payment processing failed: Amount must be greater than zero.");
            throw new IllegalArgumentException("Order amount must be greater than zero for payment.");
        }

        // Assuming payment is successful
        order.setStatus("paid");
        System.out.println("Payment processed successfully for order: " + order);

        // If payment is successful, return the order for the next stage
        return order;
    }
}

4.1 Envio

public class ShippingStage implements OrderProcessingStage {
    @Override
    public Order process(Order order) {
        // Simulate shipping processing
        if ("paid".equalsIgnoreCase(order.getStatus())) {
            order.setStatus("shipped");
            System.out.println("Order shipped successfully: " + order);
        } else {
            System.out.println("Shipping failed: Order must be paid before shipping.");
            throw new IllegalStateException("Order must be paid before shipping.");
        }

        // If shipping is successful, return the order for the next stage
        return order;
    }
}

5. Executando o pipeline

Order order = new Order("12345", 100.0);

OrderProcessingPipeline pipeline = new OrderProcessingPipeline()
                .addStages(new ValidationStage())
                .addStages(new PaymentStage())
                .addStages(new ShippingStage());
pipeline.execute(order);

Resultado no console

Order validation passed: Order{orderId='12345', amount=100.0, status='Validated'}
Payment processed successfully for order: Order{orderId='12345', amount=100.0, status='paid'}
Order shipped successfully: Order{orderId='12345', amount=100.0, status='shipped'}

Variação com Classe Abstrata e Controle de Fluxo

Agora, vamos deixar nosso Pipeline mais robusto. Vamos:

Usar uma classe abstrata em vez de interface
Adicionar controle para etapas opcionais
Validar antes de processar

1. Nova classe abstrata

Agora vamos criar a classe abstrata OrderProcessingStage, que trará mais flexibilidade ao pipeline. Ela contará com três parâmetros principais:

nameStep: nome da etapa (usado para logs e métricas);
descriptionStep: descrição da etapa (também útil para observabilidade);
byPass: um booleano que indica se o pipeline pode continuar mesmo que essa etapa falhe.

Além disso, introduziremos o método validate, que retorna um valor booleano. Ele é responsável por verificar se os dados estão corretos antes de prosseguir para a execução do process. Essa abordagem ajuda a reduzir erros e garante que cada etapa só seja processada quando as condições necessárias forem atendidas.

public abstract class OrderProcessingStage {

    private String nameStep;
    private String descriptionStep;
    private Boolean byPass;

    protected OrderProcessingStage(String nameStep, String descriptionStep, Boolean byPass) {
        this.nameStep = nameStep;
        this.descriptionStep = descriptionStep;
        this.byPass = byPass == null ? false : byPass;
    }
    abstract Order process(Order order);
    abstract Boolean validate(Order order);
// getter setter
}

2. Atualizando o Pipeline


public class OrderProcessingPipeline {

    public List<OrderProcessingStage> stages = new ArrayList<>();

    public OrderProcessingPipeline addStages(OrderProcessingStage stage) {
        // Initialize the pipeline with stages
        if (stage != null) {
            stages.add(stage);
        }
        return this;
    }

    public Order execute(Order order) {
        // Execute each stage in the pipeline
        for (OrderProcessingStage stage : stages) {
            try {
                System.out.println("Dados do estágio: " + stage.getNameStep() + ", Descrição: " + stage.getDescriptionStep());
                if (stage.validate(order)) {
                    order = stage.process(order);
                    continue;
                }

                if (!stage.validate(order) && !stage.getByPass()) {
                    System.out.println("Order processing halted due to invalid status.");
                    break; // Stop processing if the order is invalid
                }

            } catch (Exception e) {
                System.err.println("Error processing order at stage: " + stage.getClass().getSimpleName() + " - step: " + stage.getNameStep());
            }
        }
        // Return the final order after processing through all stages
        return order;
    }
}

3. Etapas com validação


public class ValidationStage extends OrderProcessingStage {

    public ValidationStage() {
        super("validation_stage", "Stage to validate the order", false);
    }

    @Override
    public Order process(Order order) {
        // Validate the order
        if (order.getAmount() <= 0) {
            order.setStatus("Invalid");
            System.out.println("Order validation failed: Amount must be greater than zero.");
            throw new IllegalArgumentException("Order amount must be greater than zero.");
        }

        order.setStatus("Validated");
        System.out.println("Order validation passed: " + order);

        // If validation passes, return the order for the next stage
        return order;
    }

    @Override
    public Boolean validate(Order order) {
        return order != null;
    }
}

Outras etapas seguem o mesmo padrão

Logs com sucesso na validação:

Dados do estágio: validation_stage, Descrição: Stage to validate the order
Order validation passed: Order{orderId='12345', amount=100.0, status='Validated'}
Dados do estágio: payment_stage, Descrição: Stage to process payment for the order
Payment processed successfully for order: Order{orderId='12345', amount=100.0, status='paid'}
Dados do estágio: shipping_stage, Descrição: Stage to ship the order
Order shipped successfully: Order{orderId='12345', amount=100.0, status='shipped'}

Como podemos observar nos logs, o nome e a descrição de cada etapa foram exibidos corretamente, e todas as etapas foram executadas com sucesso, seguindo a ordem definida.

Agora, vamos simular uma situação em que o pedido (order) está nulo e analisar o que acontece.

Logs com falha de validação:

Dados do estágio: validation_stage, Descrição: Stage to validate the order
Order processing halted due to invalid status.

Nesse cenário, o método validate identificou que os dados estavam inválidos e, por isso, interrompeu o fluxo. Como a primeira etapa não permite byPass, o pipeline foi encerrado imediatamente, sem continuar para os próximos estágios.

Antes de escolher um padrão de projeto, entenda profundamente o problema que você está tentando resolver. Nem sempre aplicar um design pattern é a melhor solução muitas vezes, seguir os princípios do SOLID já garante uma arquitetura bem organizada e sustentável.

No entanto, se optar por aplicar um padrão como o Pipeline, é importante considerar os seguintes pontos:

Vantagens do Pipeline

✅ Separação de responsabilidades
✅ Fácil manutenção e testes
✅ Reutilização de etapas
✅ Flexibilidade para reorganizar o fluxo

Desvantagens

❌ Mais código para manter
❌ Pode ter impacto de performance em grandes volumes
❌ Tratamento de erro entre estágios pode ser mais difícil

How to create Annotation in SpringBoot Java? [ENG/PT-BR]

Wagner Negrão 👨‍🔧 — Mon, 20 Nov 2023 19:01:11 +0000

How to create an @Annotation in Java SpringBoot?

Link to the post in Portuguese

I was doing a code for registration and came across two different classes but that had the same purpose. Perform a filter in the database to know if that information was already present. With this need I searched the internet and saw that a possible solution would be to create an Annotation for this validation, this way would not have the repeated code snippet.

Now to the code:

Initially you will need to create an interface, I will call ChechValue as in the file below.


@Documented
@Constraint(validatedBy = {ChechValueValidator.class})
@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
public @interface ChechValue {
    String message() default "default message";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
    String fieldName();
    Class<?> domainClass();
}

To create the annotation you must import some information for it to be executed, first the constraint that will add to the spring bean the class that is being used for validation, according to the Target that is responsible for defining which elements we will obtain and finally the Retention that is responsible for defining how this annotation will be executed, in our case will be Runtime.

That done, we can create the standard fields of an annotation like:

message() // Responsible for having a standard message or receiving a message in case of error

groups() // Responsible for defining access groups

payload() // Responsible for receiving information, something similar to the body of a request

fieldName() // In our case is responsible for defining which field will be validated

domainClass() // Responsible for defining which class will be used as Base

It is worth mentioning that it is an important convention to create the implementation file with the same interface name by adding only the Validator at the end of the class.

That done, we will implement the validation. Initially we will implement the ConstraintValidator, in it we will define the interface that will be used to create the annotation and also the object that will receive, as in the code below.


public class ChechValueValidator implements ConstraintValidator<ChechValue, Object> {

    private String domainAttribute;
    private Class<?> class;
    @PersistenceContext
    private EntityManager manager;

    @Override
    public void initialize(UniqueValue constraintAnnotation) {
        domainAttribute = constraintAnnotation.fieldName();
        class = constraintAnnotation.domainClass();
    }

    @Override
    public boolean isValid(Object object, ConstraintValidatorContext context) {
        Query query = manager.createQuery(
            "Select 1 from " +
            klass.getName() +
            " Where " +
            domainAttribute +
            " =:value");

        query.setParameter("value", object);
        List<?> list = query.getResultList();

        Assert.state(list.size() <= 1, "More than one value was identified in the class " + class.getName());

        return list.isEmpty();
    }
}

As mentioned before we will have a validation if the value is already present, soon we will need to implement EntityManager, class that we will make the filter and the attribute that will be made the filter.

In the class isValid() validation will be done, in this case the filter will be performed in the database to know if there is more than one information with the same data.

Now we have the example of Annotation being used:

public class AuthorRequest {
    @NotNull(message = "is required")
    private final String name;
    @NotNull(message = "is required")
    @Email
    @ChechValue(domainClass = Author.class, fieldName = "email")
    private final String email;
    @NotNull(message = "is required")
    @NotEmpty
    private final String description;
}

Using this Annotation we stopped having several similar code snippets but at different points of the code, helping us in more code clarity and less repetition.

Como criar uma @Annotation em SpringBoot Java?

Estava fazendo um código para cadastro e me deparei com duas classes distintas porém que possuíam a mesma finalidade. Realizar um filtro no banco de dados para saber se aquela informação já era presente. Com essa necessidade procurei na internet e vi que uma possível solução seria criar uma annotation para essa validação, desta forma não teria o trecho de código repetido.

Agora vamos ao código:

Inicialmente você vai precisar criar uma Interface, irei chamar de ChechValue como no arquivo abaixo.


@Documented
@Constraint(validatedBy = {ChechValueValidator.class})
@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
public @interface ChechValue {
    String message() default "default message";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
    String fieldName();
    Class<?> domainClass();
}

Para criar a anotação deve-se importar algumas informações para que ela seja executada, primeiro o Constraint que irá adicionar ao bean do spring a classe que está sendo utilizada para validação, segundo o Target que fica responsável por definir quais elementos iremos obter e por fim o Retention que é responsável por definir como será executada essa anotação, em nosso caso será Runtime.

Feito isso, podemos criar os campos padrões de uma anotação como:

message() // Responsável por ter uma mensagem padrão ou receber uma mensagem em caso de erro

groups() // Responsável por definir grupos de acesso

payload() // Responsável por receber informação, algo similar ao body de uma request

fieldName() // Em nosso caso é responsável por definir qual campo será validado

domainClass() // Responsável por definir qual classe será utilizada como Base

Vale ressaltar que é uma convenção importante criar o arquivo de implementação com o mesmo nome da interface adicionando apenas o Validator no fim da classe.

Feito isso, iremos implementar a validação. Inicialmente vamos implementar o ConstraintValidator, nele iremos definir a interface que será utilizada para criar a anotação e também a objeto que irá receber, como no código abaixo.


public class ChechValueValidator implements ConstraintValidator<ChechValue, Object> {

    private String domainAttribute;
    private Class<?> class;
    @PersistenceContext
    private EntityManager manager;

    @Override
    public void initialize(UniqueValue constraintAnnotation) {
        domainAttribute = constraintAnnotation.fieldName();
        class = constraintAnnotation.domainClass();
    }

    @Override
    public boolean isValid(Object object, ConstraintValidatorContext context) {
        Query query = manager.createQuery(
            "Select 1 from " +
            klass.getName() +
            " Where " +
            domainAttribute +
            " =:value");

        query.setParameter("value", object);
        List<?> list = query.getResultList();

        Assert.state(list.size() <= 1, "More than one value was identified in the class " + class.getName());

        return list.isEmpty();
    }
}

Como mencionado anteriormente iremos ter uma validação se o valor já é presente, logo precisaremos implementar o EntityManager, classe que iremos fazer o filtro e o atributo que será feito o filtro.

Na classe isValid() será feito a validação, nesse caso será realizado o filtro no banco de dados para sabermos se existe mais de uma informação com o mesmo dado.

Agora temos o exemplo da annotation sendo utilizada:


public class AuthorRequest {
    @NotNull(message = "is required")
    private final String name;
    @NotNull(message = "is required")
    @Email
    @ChechValue(domainClass = Author.class, fieldName = "email")
    private final String email;
    @NotNull(message = "is required")
    @NotEmpty
    private final String description;
}

Utilizando essa annotation deixamos de termos vários trechos de código parecidos porém em pontos diferentes do código, nos auxiliando em mais clareza de código e menos repetição.

What are Generics in Java?

Wagner Negrão 👨‍🔧 — Wed, 25 Jan 2023 22:43:33 +0000

Hello, today I will talk about Generics in Java, this text is focused on beginners who seek to learn a little more about Java.

Generics is an undefined type that can assume any kind, it has been added to Java seeking to avoid excessive code or casting repetitions.

To make it clearer we will create a scenario in which we need to print an object, but we do not know what types will use our method.

I will create the animal abstract class and extend it from two Dog and Cat classes.

abstract class Animal {
    public abstract void search();
}

class Dog extends Animal {
    String dog;

    public Dog(String dog) {
        this.dog = dog;
    }

    @Override
    public void search() {
        System.out.println("find Dog");
    }

    // Method to string was omitted.
}

class Cat extends Animal {

    String cat;

    public Cat(String cat) {
        this.cat = cat;
    }

    @Override
    public void search() {
        System.out.println("find Cat");
    }

    // Method to string was omitted.
}

Now let's create a method to present the information of an object at the terminal, as a rule, we can define that every method that has one toString() can be presented by the so-called Print. We can see that in class Printer() we do not have the specific type to be passed on the builder, it can be any object, the method print will present the information and if it does not have the method toString() the object's memory address will be presented. This method is that in some cases we want to present some information on Debug we can invoke this method.

class Printer <T> {
    T toPrint;

    public Printer(T toPrint) {
        this.toPrint = toPrint;
    }

    public void print() {
        System.out.println(toPrint);
    }
}

Case 01:

public class Main {
    public static void main(String[] args) {
        Dog dog = new Dog("Dog");
        Cat cat = new Cat("Cat");

        Printer<Integer> printer = new Printer(dog);
        printer.print();
    }
}

Now let's create a method to print the lists.

public static void printAnimal(List<? extends Animal> animals) {
    animals.stream().forEach(a -> a.search());
}

In this method is defined the type of the list as whatever type extend of animals, an important information is that we can not add anything to the list because Java in compilation time does not know what is within the list, so we will have the error in compilation time and not execution.

In this method we will all have Animal extension, containing Cat and Dog, this guarantees us a defensive programming, ensuring that we will present only what we want and nothing beyond.

Case 02:

public class Main {
    public static void main(String[] args) {
        Dog dog = new Dog("Dog");
        Cat cat = new Cat("Cat");

        List<Dog> dogList = Arrays.asList(dog);
        List<Cat> catList = Arrays.asList(cat);
        List<Animal> animals = Arrays.asList(dog, cat);

        printAnimal(dogList);
        printAnimal(catList);
        printAnimal(animals);
    }
}

Now I will present the last case that aims to create a list of 2 objects of different types.


public static <T, V> List<Object> createList(T thing, V otherThing) {

    return Arrays.asList(thing, otherThing);
}

This method is possible to create a list of different types without worrying about what will be inserted, this is useful when we have a situation that we can receive information that is not expected, so we can guarantee that we will be able to receive the information and later treat it.

In this case we will only make the object print on the terminal, but the idea is to understand basicly to apply to something larger.

Case 03:


public class Main {
    public static void main(String[] args) {
        Dog dog = new Dog("Dog");
        Cat cat = new Cat("Cat");

       createList(dog, cat).stream().forEach(e -> {
           System.out.println(e);
       });
    }
}

An important thing is to know that generics exist only in the time of compilation in this way it keeps back the retro compatibility with Java versions, another important point is to point out that the examples presented here are for didactic purposes.

Improving the way to use if in your code

Wagner Negrão 👨‍🔧 — Thu, 22 Dec 2022 13:29:55 +0000

The way we use 'ifs' is usually about validating a positive case, and if it is not that case then we should go to an Else, this form technically is not wrong, but we should pay attention to better ways to implement these validations.


if (user.isPresent()) {
    User.toDto(user.get())
    // More actions for success
} else {
    // Do something for error case
}

// continues the code

Currently, languages of programming like Golang have a different way when using the 'if', which would be to validate the case of error if not exist, then should continue the normal flow of the code.

user, err := receiveUser()

if err != nil {
    return err
}

userDto := convertUser(user)

// continues the code flow

We can see that this way of implementation is cleaner, this enables making code clean for whoever is reading.

Now we can see that code remains with the same complexity although cleaner, the way of validating the error case for the first seeks ensures the integrity of information as soon as it is received, bringing defensive programming to the code.


if (!user.isPresent()) {
    // Do something for error case
}

User.toDto(user.get())

// More actions for success
// continues the code flow

A good way to practice this methodology is using the type 'Optional' that fits perfectly to what we need or creating ways to evaluate a possible error, such as, if you are receiving a list you must validate if it is empty and after making some interaction, another way, validate strings if are empty before the use. These are simple examples, but the idea here is to understand how to start this practice.

I always indicate to seek the type 'Optional', but when it is not possible, we can use this technique to try to help us build a more defensive and clean code.

It is worth remembering that this post is not saying what way to write 'if' it is better but to present a way cleaner to declare an 'if'.

Difference between Entity and DTO

Wagner Negrão 👨‍🔧 — Tue, 20 Dec 2022 21:04:46 +0000

This post seeks to present entity and DTO in a low complexity aiming at the beginner developer.

Entities are classes that have a relation intrinsic to the business, for example, a class that maps a table of databases so has Id and other fields.


 java
{
private Long id;
private String firstName;
private String lastName;
private String email
}

Value Object or Data Transfer Object are classes that aim to map fields from an entity, add functions or remove fields. This basically consists of transitioning fields within the project.


 java
{
private String firstName;
private String lastName;
private String email
}

The Dto it have some characteristics, like the principle of immutable, and also serve like filter to fields received in a request body for example a field of email that can do a regex before of we pass this field to an entity.

The relationship between entity and DTO may be as follows.

This mode aims to be able to abstract certain fields for those who will receive the information.

Example:

Above we have the FirstName and LastName fields inside the entity, we can return a field called FullName that concatena this fields and returns a single field, soon we would have something like.


 java
{
private String fullName;
private String email;
}

Now we have the opposite that it will be external information for the entity.

With the information we are receiving as a Request Body we can make validations such as to check the email standard will be accepted or the amount of characteristics. This enables the maintenance of the integrity of the data that will be transacted within the application, protecting the core of the application.

Exception Checked VS Unchecked in Java

Wagner Negrão 👨‍🔧 — Mon, 16 Aug 2021 15:56:50 +0000

Hello, today I’ll speak about exceptions often when programming we came across with exceptions and use the advantages of IDE that we use to write the exception more adequately, but know only this isn’t enough, we must understand that exist two types of exception the checked and unchecked, to throw the exception adequate.

Firstly, the exceptions have a hierarchy all inherit of Exception. Each exception that extends creates your type of exceptions, but each exception has types like checked and unchecked that identify like will work into code, see the image below.

The exceptions checked are present in operations that represent an application risk, they can be native or not, like example SQLException, since all these are inherited directly from java.lang.Exception, father of all exceptions in Java.

See the example below:

public double calc(double a, double b) {
        throws SumException {
            double value = (a)/(b*b);
            if (value <= 18.5) {
                throw new SumException("Example exception checked !");
            }
    }

The exceptions checked are treated or declared in the header of a method, because are related to the structure of the code and present the risk of exceptions, in this case, are switched on with exceptions that extend Exception. Basically, exceptions checked are related to the structure of code and extends of Exception, which can be exception native or exception created.

The exceptions unchecked are present in the run time of compilation, have inherited of RunTimeException, these exceptions aren’t expected directly when writing an application like example NullPointerException, this exception possibly will occur in run time.

See the example below:

try {
        File file = new File("path");
        FileInputStream fis = new FileInputStream(file);
    } catch(FileNotFoundException e) { ... some code ...}

The exceptions unchecked will occur in rum time, case not it is treaty although not need of treaty, must be taken into consideration. Basically, exceptions unchecked are throw in run time and extend to the RunTimeException class.

Into the book, The Java programming language says "exceptions of run time unchecked represent conditions that, in general, reflect an error in logic into your program and not can be reasonably recovered at run time". So we should pay attention when we write code and create the exception, see the structure of exceptions.

When throw exception and which?

The exception is something powerful to an error handler in a programming language, so respect the structure in layers. Should create the politic of exceptions into of project to check and throw an exception, a good practice creates exceptions to specific cases and not return exception pure but clarify better that is happening. Now, which exception use to create this depends on the code that you are writing . No silver bullet.