DEV Community: Bruno

Spring Boot Actuator

Bruno — Tue, 21 Apr 2026 06:11:57 +0000

O que é o Spring Boot Actuator?

O Spring Boot Actuator é um módulo do Spring Boot que fornece funcionalidades prontas para monitoramento, gerenciamento e observabilidade de aplicações em tempo de execução.

Ele expõe endpoints HTTP que permitem inspecionar o estado interno da aplicação sem precisar modificar o código ou reiniciar o sistema.

Endpoints Principais

Método	Endpoint	Descrição
GET	`/actuator/health`	Status da aplicação e sub-componentes (DB, Redis, disco...)
GET	`/actuator/metrics`	Lista todas as métricas disponíveis (JVM, HTTP, CPU...)
GET	`/actuator/info`	Informações da aplicação (versão, build, git commit...)
GET	`/actuator/env`	Variáveis de ambiente e propriedades de configuração
GET	`/actuator/beans`	Todos os beans Spring registrados no contexto
GET	`/actuator/mappings`	Todos os mapeamentos de rotas HTTP (@RequestMapping)
GET	`/actuator/loggers`	Nível de log de cada logger da aplicação
POST	`/actuator/loggers/{name}`	Altera nível de log em tempo real (sem restart!)
GET	`/actuator/threaddump`	Thread dump completo da JVM
GET	`/actuator/prometheus`	Métricas no formato Prometheus (requer Micrometer)

⚠️ Por padrão, apenas /health e /info são expostos via HTTP.

Configuração (`application.properties` / `application.yml`)

Expor todos os endpoints

management.endpoints.web.exposure.include=*
management.endpoint.health.show-details=always

Expor apenas endpoints específicos

management.endpoints.web.exposure.include=health,info,metrics
management.endpoints.web.exposure.exclude=env,beans

Mudar a porta e o base path

management.server.port=8081
management.endpoints.web.base-path=/manage

Customização

Health Indicator customizado

@Component
public class MinhaIntegracaoHealth implements HealthIndicator {
    @Override
    public Health health() {
        boolean ok = verificarIntegracao();
        return ok
            ? Health.up().withDetail("api", "online").build()
            : Health.down().withDetail("erro", "timeout").build();
    }
}

O Actuator serve para:

Monitorar a saúde da aplicação
Expor métricas de desempenho
Diagnosticar problemas em produção
Integrar com ferramentas de observabilidade
Gerenciar comportamento da aplicação em runtime

Health Check Endpoint:

/actuator/health
Permite verificar se a aplicação está funcionando corretamente.

Métricas (Micrometer) Endpoint: /actuator/metrics

Fornece dados como:
Tempo de resposta
Uso de memória
Número de requisições
Taxa de erro

Logs dinâmicos Endpoint:

/actuator/loggers
Permite alterar o nível de log sem reiniciar a aplicação.

Informações da aplicação Endpoint:

/actuator/info
Exibe informações como versão, nome e build.

ATENÇÃO

** Deve ser protegido em produção.**

Ambiente e configurações Endpoint:

/actuator/env
Mostra propriedades e variáveis de ambiente.

Beans do Spring Endpoint:

/actuator/beans
Lista todos os componentes carregados pelo Spring.

Integração com Prometheus Endpoint:

/actuator/prometheus
Permite exportar métricas para ferramentas como Prometheus e Grafana.

O que o Actuator resolve?

Sem o Actuator:

Dificuldade para monitorar aplicação
Debug complicado em produção
Falta de visibilidade sobre performance

Com o Actuator:

Observabilidade centralizada
Diagnóstico rápido
Monitoramento contínuo

Use o Actuator quando:

Ele transforma sua aplicação em um sistema observável, permitindo:

Monitorar saúde
Acompanhar métricas
Diagnosticar problemas
Integrar com ecossistemas de cloud
Dominar o Actuator significa dar um passo importante para trabalhar com sistemas distribuídos, microserviços e ambientes de produção reais.

#4 Docker - Volumes

Bruno — Sat, 14 Mar 2026 17:28:28 +0000

Docker Volumes

Volumes são mecanismos utilizados pelo Docker para persistir dados
fora do ciclo de vida dos containers.

Por padrão, containers são efêmeros, ou seja, quando um container é
removido, os dados armazenados dentro dele também são perdidos. Volumes
permitem que os dados sejam armazenados no host, garantindo
persistência.

Características dos Volumes

Persistem dados mesmo após o container ser removido
Podem ser compartilhados entre múltiplos containers
São gerenciados pelo Docker
Ficam armazenados no host
Local padrão no Linux: /var/lib/docker/volumes

Criando um Volume

Criar volume:

docker volume create meu-volume

Listar volumes:

docker volume ls

Inspecionar volume:

docker volume inspect meu-volume

Remover volume:

docker volume rm meu-volume

Utilizando Volume em um Container

Exemplo com nginx:

docker run -d \
--name nginx-container \
-v meu-volume:/usr/share/nginx/html \
nginx:1.27-alpine

Estrutura:

Host
 │
 └─ Volume (meu-volume)
      │
      └─ Container nginx
           └─ /usr/share/nginx/html

Tipos de Persistência:

Volume (gerenciado pelo Docker)

-v meu-volume:/data
Bind Mount (diretório do host)

-v ./dados:/data

Compartilhando Volume entre Containers

docker run -d --name container1 -v shared-volume:/app nginx
docker run -d --name container2 -v shared-volume:/app nginx

Ambos os containers acessam os mesmos dados.

Resumo

Conceito	Descrição
Volume	Persistência de dados no Docker
Container	Ambiente efêmero
Bind Mount	Pasta do host montada dentro do container
Compartilhamento	Volumes podem ser utilizados por vários containers

#3 Docker - Network

Bruno — Sat, 14 Mar 2026 17:19:55 +0000

Comunicação entre Containers

Por padrão, containers Docker são isolados. Para que eles consigam se comunicar entre si, é necessário conectá-los a uma mesma rede Docker.

Docker cria automaticamente uma rede chamada bridge, mas também é possível criar redes customizadas, que oferecem melhor isolamento e resolução de nomes entre containers.

Tipos de rede

Bridge (padrão), rede padrão usada para comunicação entre containers no mesmo host.
Host, container usa diretamente a rede do host.
Overlay, rede usada em clusters para comunicação entre múltiplos hosts.
Macvlan, permite que containers recebam IP próprio na rede física.

Comandos

criando - docker network create --driver bridge minha-rede
listando - docker network ls
inspecionando - docker network inspect minha-rede
conectando - docker network connect minha-rede container_existente
removendo - docker network rm minha-rede

#2 Docker - Cotainers

Bruno — Sat, 14 Mar 2026 17:10:12 +0000

Um container é uma instância em execução de uma imagem.

Quando uma imagem é executada usando Docker, o Docker cria um container isolado onde a aplicação roda, uma mesma imagem pode gerar múltiplos containers simultaneamente.

Containers são ambientes isolados que não armazenam estado por padrão. Eles executam de forma independente do sistema operacional host e não possuem comunicação nativa direta com outros containers ou com o host sem configuração de rede explícita. Além disso, containers são efêmeros: quando o processo principal termina, o container é encerrado e qualquer estado interno pode ser perdido caso não haja mecanismos de persistência, como volumes.

Características importantes dos containers

Containers executam um processo principal (PID 1)
Compartilham o kernel do sistema operacional host
São efêmeros e descartáveis
Utilizam sistemas de arquivos em camadas
Possuem isolamento de recursos via namespaces e cgroups
Podem se comunicar através de redes Docker
Dados persistentes devem ser armazenados em volumes

Relação entre imagem e container

Imagem
↓ executando - Docker run
Container

Comandos Comuns

docker run → cria e inicia container
docker stop → para container
docker start → inicia container novamente
docker rm → remove container

docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND]
docker run -d -p 8080:80 --name meu-nginx nginx:1.27-alpine

#1 Docker - Imagens

Bruno — Sun, 08 Mar 2026 16:20:29 +0000

Imagens

As imagens são pacotes imutáveis de um projeto/aplicação disponiveis para execução.

Por exemplo:

Postgres
Prometheus
Rabbit

As imagens funcionam como um template ou blueprint para criar containers.

Características das imagens

Imutáveis → não são alteradas após criadas
Versionadas através de tags
Reutilizáveis
Armazenadas em registries (Docker Hub, ECR, ACR, etc.) ou local no host

Containers

Os containers são instancias dessas imagens em execução ou seja apos executar uma imagem ela automaticamente vira um container.

Quando uma imagem é executada usando Docker, o Docker cria um container isolado onde a aplicação roda, esse container não conhece o seu host e você pode ter a mesma imagem rodando X vezes no meu host em container separados.

Replicação & Sharding

Bruno — Sat, 14 Jun 2025 17:48:43 +0000

📘 Replicação e Sharding: Conceitos, Diferenças e Vantagens

1. Introdução

Sistemas de banco de dados distribuídos muitas vezes precisam lidar com grandes volumes de dados, alta disponibilidade e tolerância a falhas. Para atender essas demandas, duas técnicas fundamentais são amplamente utilizadas: replicação e sharding.

2. O que é Replicação?

Replicação é o processo de copiar e manter os mesmos dados em múltiplos servidores

🔧 Como funciona:

Um servidor principal aceita operações de escrita.
Um ou mais servidores secundários Replicas mantêm cópias sincronizadas dos dados.
As réplicas geralmente são atualizadas de forma assíncrona ou semissíncrona.

✅ Vantagens:

Alta disponibilidade: se o servidor principal falhar, uma réplica pode assumir seu papel.
Melhor desempenho de leitura: consultas podem ser distribuídas entre os nós.
Backups mais seguros: réplicas podem ser usadas para realizar backups sem impactar o sistema principal.

3. O que é Sharding?

Sharding é o processo de dividir os dados em partes menores chamadas (Região, tipo ou por hashing) de "shards", que são armazenadas em diferentes servidores.

🔧 Como funciona:

Cada shard contém uma fração dos dados, baseada em uma chave (ex: ID do cliente).
Cada servidor armazena apenas uma parte dos dados totais.
Consultas são roteadas ao shard correto com base nessa chave.

✅ Vantagens:

Escalabilidade horizontal: mais servidores podem ser adicionados conforme o volume de dados cresce.
Melhor desempenho de escrita e leitura: reduz a sobrecarga em cada servidor.
Capacidade de armazenamento distribuída: dados grandes são particionados entre servidores.

4. Pode-se usar os dois juntos?

Sim! Em sistemas grandes, é comum combinar sharding + replicação:

Cada shard pode ter suas próprias réplicas.
Isso oferece escalabilidade e alta disponibilidade ao mesmo tempo.

5. Conclusão

Tanto replicação quanto sharding são técnicas essenciais no design de sistemas distribuídos modernos.

Use replicação se seu foco for tolerância a falhas e desempenho de leitura.
Use sharding se seu foco for escalabilidade e desempenho com grandes volumes de dados.

A escolha correta depende das necessidades específicas da aplicação e da infraestrutura disponível.

SAGA

Bruno — Sun, 01 Jun 2025 13:05:42 +0000

O que é?

O padrão de projeto SAGA é um padrão arquitetural usado principalmente para gerenciar transações distribuídas em sistemas de microsserviços. Ele foi criado para resolver o problema de coerência de dados em ambientes onde não é possível ou desejável usar uma transação distribuída tradicional (como uma transação ACID que envolve múltiplos bancos de dados ou serviços).

O que é uma "transação distribuída"?

É uma operação que envolve múltiplos serviços ou múltiplas bases de dados, onde todos precisam ser consistentes no final. O desafio é: se algo falhar no meio, como desfazer o que já foi feito?

Uma SAGA é uma sequência de transações locais em diferentes serviços, onde cada transação é seguida por uma ação compensatória (rollback local) caso algo dê errado.

🔧 Como funciona?

Existem dois tipos principais de implementação do padrão SAGA:

Orquestrado

Existe um orquestrador central que comanda o fluxo de transações.
Ele chama cada serviço na ordem correta e, em caso de falha, executa as transações compensatórias.
Mais facil de adicionar um fluxo novo
Mais facil de dar manutenção
Leitura de codógio mais facil

Coreografado

No padrão coreografado, não existe um orquestrador central. Cada serviço é responsável por ouvir eventos e executar sua parte da transação de forma autônoma. O fluxo é determinado pelos eventos que os serviços emitem e consomem.

Quando um serviço completa sua tarefa, ele publica um evento (por exemplo, EstoqueReservado), e o próximo serviço no fluxo ouve esse evento e age (por exemplo, o serviço de pagamento escuta e processa o pagamento).

Se algo falhar no meio do processo, os serviços devem emitir eventos de compensação, permitindo que os serviços anteriores façam o "rollback" por meio de suas ações compensatórias, normalmente seguindo a ordem inversa da execução.

🧰 Ferramentas para Design e Execução

Existem ferramentas que ajudam tanto no design visual quanto na execução real dos fluxos do padrão Saga. Uma das mais conhecidas é o:

Camunda: plataforma de automação de processos baseada em BPMN (Business Process Model and Notation).
- Permite modelar visualmente o fluxo da saga.
- Pode ser integrada diretamente ao código para controlar os serviços e eventos.
- Suporta tanto orquestração quanto coreografia, dependendo da arquitetura adotada.

Outras ferramentas que também podem ser usadas para coreografia de eventos incluem:

Apache Kafka (com Event-Driven Architecture)
Axon Framework (em Java)
Temporal.io (workflow orchestration, mas pode ser usado de forma
híbrida)

Clean Architecture

Bruno — Sun, 11 May 2025 22:46:51 +0000

🧱 O que é a Clean Architecture?

A Clean Architecture, proposta por Uncle Bob (Robert C. Martin), é um modelo de arquitetura em camadas que tem como objetivo principal manter o núcleo do sistema isolado de frameworks, bibliotecas e tecnologias externas.

O foco está em garantir que as regras de negócio fiquem desacopladas, facilitando testes, manutenção e troca de tecnologias ao longo do tempo.

🌐 Camadas explicadas (de fora para dentro):

Nenhuma camada de dentro deve conhecer a camada para fora dela

-> = Conhece

lemos sempre azul -> verde -> amarela -> vermelha

🔵 Camada externa (azul):
Contém frameworks, bancos de dados, bibliotecas de terceiros, servidores web e qualquer tecnologia externa. Ela depende das camadas internas, mas não é dependida por elas.

🟢 Camada intermediária (verde):
Abriga os adapters, como controllers, presenters e gateways. Essa camada é responsável por traduzir dados entre o mundo externo e o core do sistema.

🟡 Casos de Uso:
Aqui ficam os use cases, que coordenam regras de negócio e orquestram chamadas para interfaces. Eles usam interfaces para se comunicar com a camada externa (ex: persistência, envio de e-mail).

🔴 Entidades (Domínio):
O núcleo do sistema. Essa camada contém as regras de negócio puras, como validações e cálculos que não dependem de nada externo.
Exemplo: uma validação de CPF ou o cálculo do total de um pedido.

✅ Vantagens

Alta testabilidade (core não depende de infra)
Facilidade de manutenção e evolução
Baixo acoplamento
Independência de frameworks e bancos
Reutilização de lógica de negócio

⚠️ Desvantagens

Curva de aprendizado mais alta
Mais código e estrutura para coisas simples
Pode parecer overkill para projetos pequenos
Demanda disciplina para manter separação clara de camadas

#7 DP: Observer

Bruno — Wed, 07 May 2025 17:03:10 +0000

O que é o Padrão Observer?

O Observer é um padrão de projeto comportamental que define uma relação de dependência entre objetos, onde um objeto (o sujeito) notifica automaticamente outros objetos (os observadores) sempre que seu estado muda. Ele é muito útil quando várias partes do sistema precisam reagir a mudanças em um mesmo ponto.

Esse padrão promove o desacoplamento entre quem emite o evento e quem reage a ele, permitindo que novos observadores sejam adicionados ou removidos em tempo de execução, sem alterar o sujeito.

Em resumo, o Observer estabelece um mecanismo de notificação automática, garantindo que todos os interessados estejam atualizados sempre que algo importante acontece.

Exemplo:

As classes que devem reagir a mudanças se inscrevem no sujeito responsável por emitir essas mudanças.

A classe principal recebe os observadores via o método addObserver(), registrando as implementações interessadas em ser notificadas.

O método newStockData() executa a ação principal e, em seguida, notifica todos os observadores inscritos, permitindo que eles executem suas responsabilidades de forma independente.

Assim caso surja uma demanda de adicionar uma nova açãoao newStockData, você não precisaria modificar a classe

#6 DP: Decorator

Bruno — Tue, 06 May 2025 18:05:02 +0000

O que é o Padrão Decorator?

O Decorator é um padrão de projeto estrutural que permite adicionar comportamentos adicionais a um objeto de forma dinâmica. Ele permite que você encadeie funcionalidades (como validação, construção, logging e outras) em um fluxo sequencial, sem modificar a estrutura original da classe. Isso possibilita adicionar ou remover comportamentos com facilidade, mantendo o código mais flexível e desacoplado.

Em resumo, o Decorator cria uma cadeia de responsabilidades onde cada classe pode adicionar sua funcionalidade à sequência, sem afetar as outras.

Exemplo prático

Imagina que você precisa realizar várias validações (como validar o usuário, estoque e status), mas não quer que elas fiquem fortemente acopladas. O objetivo é poder adicionar, remover ou reorganizar facilmente as validações sem mexer nas classes existentes.

Sem o Decorator:

Sem o padrão Decorator, você teria algo assim:

Cada validação seria chamada individualmente, uma após a outra, com código acoplado e sem flexibilidade para adicionar ou remover comportamentos sem alterar diretamente o código.

public class MyClass {
    public static void main(String args[]) {
        Object request = new Object();

        ValidaEstoque validaEstoque = new ValidaEstoque();
        validaEstoque.valida(request);

        ValidaUsuario validaUsuario = new ValidaUsuario();
        validaUsuario.valida(request);

        ValidaStatus validaStatus = new ValidaStatus();
        validaStatus.valida(request);
    }
}

public class ValidaEstoque {
    public static void valida(Object request) {
        // lógica de validação de estoque
    }
}

public class ValidaUsuario {
    public static void valida(Object request) {
        // lógica de validação de usuário
    }
}

public class ValidaStatus {
    public static void valida(Object request) {
        // lógica de validação de status
    }
}

Com o Decorator:
Com o padrão Decorator, você pode encadear validações de forma dinâmica, passando o "próximo" validador para o próximo da cadeia. Isso facilita a extensão e a modificação das validações sem mexer no código das classes específicas.

Cada "decorador" implementa uma lógica de validação e, ao final, passa a responsabilidade para o próximo validador da cadeia.

public class MyClass {
    public static void main(String[] args) {
        Object request = new Object();

        // Encadeando os validadores
        Valida validador = new ValidaEstoque(
                                new ValidaUsuario(
                                    new ValidaStatus()));

        validador.valida(request);
    }
}

// Interface base para os validadores
interface Valida {
    void valida(Object request);
}

// Validador abstrato base com lógica comum
abstract class BaseValidadorDecorator implements Valida {
    protected Valida proximo;

    public BaseValidadorDecorator(Valida proximo) {
        this.proximo = proximo;
    }

    @Override
    public void valida(Object request) {
        executarValidacao(request);
        if (proximo != null) {
            proximo.valida(request);  // Chama o próximo validador
        }
    }

    protected abstract void executarValidacao(Object request);
}

// Validador de Status (último da cadeia, mas seguro sozinho)
class ValidaStatus extends BaseValidadorDecorator {
    public ValidaStatus() {
        super(null);  // Não há próximo validador
    }

    @Override
    protected void executarValidacao(Object request) {
        System.out.println("Validando status...");
        // Lógica de validação de status
    }
}

// Validador de Usuário
class ValidaUsuario extends BaseValidadorDecorator {
    public ValidaUsuario(Valida proximo) {
        super(proximo);
    }

    @Override
    protected void executarValidacao(Object request) {
        System.out.println("Validando usuário...");
        // Lógica de validação de usuário
    }
}

// Validador de Estoque
class ValidaEstoque extends BaseValidadorDecorator {
    public ValidaEstoque(Valida proximo) {
        super(proximo);
    }

    @Override
    protected void executarValidacao(Object request) {
        System.out.println("Validando estoque...");
        // Lógica de validação de estoque
    }
}

Vantagens do Decorator:

Flexibilidade: Você pode adicionar ou remover validadores facilmente, sem alterar a estrutura do código. Só precisa instanciar e passar os decoradores na ordem desejada.

Desacoplamento: Cada validador é independente e sabe apenas sobre a sua validação e o "próximo", sem depender de implementações específicas.

Extensibilidade: Se precisar adicionar mais validações, basta criar uma nova classe que implemente BaseValidadorDecorator e passá-la na cadeia.

Melhor manutenção: Como o código é mais modular, fica mais fácil de entender, testar e manter.

#5 DP: Adapter

Bruno — Sat, 03 May 2025 12:59:29 +0000

O que é?

O Adapter é um padrão de projeto estrutural que tem como objetivo "traduzir" ou adaptar o funcionamento de um código X para que seja compatível com o código Y.

Imagine que você tem várias classes de pagamento que implementam uma interface comum chamada Pagamento — por exemplo: Pix, Ted e Boleto.

Agora, sua equipe precisa integrar uma nova forma de pagamento, como PayPal, desenvolvida por outra squad ou vinda de uma biblioteca de terceiros. Essa classe PayPal não implementa a interface Pagamento, e isso quebraria o padrão da sua aplicação.

Para resolver esse problema sem modificar a biblioteca externa (o que muitas vezes nem é possível), usamos o padrão Adapter, que atua como um "tradutor" entre as interfaces. Ele faz com que a classe PayPal seja compatível com a interface Pagamento, sem que a classe original precise ser alterada.

Quando usar Adapter:

Quando você quer usar uma classe existente, mas ela não implementa a interface esperada.
Quando não é possível modificar a classe original (ex: código de terceiros).

Exemplo:

public interface Pagamento {
    void pagar(double valor);
}

// CLASSE EXTERNA( NAO MODIFICAVEL)
public class PayPalApi {
    public void sendPayment(double amount) {
        System.out.println("Pagamento de R$" + amount + " feito via PayPal.");
    }
}

// Adapter mantendo o padrão de pagamentos 
// Invoca a biblioteca terceira
public class PayPalAdapter implements Pagamento {
    private PayPalApi paypal;

    public PayPalAdapter(PayPalApi paypal) {
        this.paypal = paypal;
    }

    @Override
    public void pagar(double valor) {
        paypal.sendPayment(valor); // adapta a chamada
    }
}

Se a biblioteca do PAYPAL tiver alguma alteração o código client fica desacoplado dessas alterações

🎯 Cenário 2: Leitor de Cartão SD vs. Cartão MicroSD
Sua aplicação trabalha com leitores que aceitam CartaoSD, mas agora você precisa usar um CartaoMicroSD (incompatível). Usamos um Adapter para que o CartaoMicroSD funcione no leitor padrão.

public interface CartaoSD {
    String lerDados();
}

// Classe que já funciona (padronizada)
public class CartaoSDOriginal implements CartaoSD {
    @Override
    public String lerDados() {
        return "Dados lidos do cartão SD.";
    }
}

// Classe incompatível( precisa de tradução )
public class CartaoMicroSD {
    public String acessarDados() {
        return "Dados lidos do cartão MicroSD.";
    }
} 

// Adapter 
public class MicroSDAdapter implements CartaoSD {
    private CartaoMicroSD microSD;

    public MicroSDAdapter(CartaoMicroSD microSD) {
        this.microSD = microSD;
    }

    @Override
    public String lerDados() {
        return microSD.acessarDados(); // adaptação da chamada
    }
}

#4 DP: Facade

Bruno — Fri, 02 May 2025 12:06:01 +0000

O que é?

O Facade é um padrão de projeto do tipo estrutural. Ele consiste na criação de uma classe intermediária (ou fachada) que expõe uma interface simplificada para um conjunto de classes ou processos mais complexos.

Seu principal objetivo é desacoplar a lógica de negócios da complexidade de múltiplas instâncias e chamadas internas, permitindo que outras partes do sistema interajam com uma interface unificada e mais limpa. Isso melhora a organização do código, facilita a manutenção e reduz a dependência direta de implementações internas.

Exemplo

Antes:

Sua classe de serviço conhecendo todas as instancias e invocações

@Service
public class PedidoService {

    private final EstoqueService estoqueService;
    private final PagamentoService pagamentoService;
    private final EmailService emailService;

    public PedidoService(EstoqueService estoqueService,
                         PagamentoService pagamentoService,
                         EmailService emailService) {
        this.estoqueService = estoqueService;
        this.pagamentoService = pagamentoService;
        this.emailService = emailService;
    }

    public void processarPedido() {
        Cliente cliente = new Cliente("João");
        Produto produto = new Produto("Notebook");

        if (estoqueService.temProduto(produto)) {
            pagamentoService.processarPagamento(cliente, produto);
            emailService.enviarConfirmacao(cliente);
        } else {
            throw new RuntimeException("Produto sem estoque.");
        }
    }
}

Depois com Facade:
O fluxo desacoplado da classe serviço:

Evitar regras complexas em classes facade

public class PedidoService {

    private final EstoqueService estoqueService;
    private final PedidoFacade pedidoFacade;

    public PedidoService(EstoqueService estoqueService, PedidoFacade pedidoFacade) {
        this.estoqueService = estoqueService;
        this.pedidoFacade = pedidoFacade;
    }

    public void processarPedido() {
        Cliente cliente = new Cliente("João");
        Produto produto = new Produto("Notebook");

        if (!estoqueService.temProduto(produto)) {
            throw new RuntimeException("Produto sem estoque.");
        }

        pedidoFacade.finalizarPedido(cliente, produto);
    }
}

public class PedidoFacade {

    private final PagamentoService pagamentoService;
    private final EmailService emailService;

    public PedidoFacade(PagamentoService pagamentoService, EmailService emailService) {
        this.pagamentoService = pagamentoService;
        this.emailService = emailService;
    }

    public void finalizarPedido(Cliente cliente, Produto produto) {
        pagamentoService.processarPagamento(cliente, produto);
        emailService.enviarConfirmacao(cliente);
    }
}

Esse padrão ajuda especialmente quando você tem processos que precisam ser reutilizados em mais de uma parte do sistema, encapsulando toda a complexidade por trás de uma única interface limpa.

DEV Community: Bruno

Spring Boot Actuator

O que é o Spring Boot Actuator?

Configuração (application.properties / application.yml)

Expor todos os endpoints

Expor apenas endpoints específicos

Mudar a porta e o base path

Customização

Health Indicator customizado

O Actuator serve para:

ATENÇÃO

O que o Actuator resolve?

Use o Actuator quando:

#4 Docker - Volumes

Docker Volumes

Características dos Volumes

Criando um Volume

Utilizando Volume em um Container

Compartilhando Volume entre Containers

Resumo

#3 Docker - Network

Comunicação entre Containers

Tipos de rede

Comandos

#2 Docker - Cotainers

Características importantes dos containers

Comandos Comuns

#1 Docker - Imagens

Imagens

Características das imagens

Containers

Replicação & Sharding

📘 Replicação e Sharding: Conceitos, Diferenças e Vantagens

1. Introdução

2. O que é Replicação?

🔧 Como funciona:

✅ Vantagens:

3. O que é Sharding?

🔧 Como funciona:

✅ Vantagens:

4. Pode-se usar os dois juntos?

5. Conclusão

SAGA

O que é?

O que é uma "transação distribuída"?

🔧 Como funciona?

Existem dois tipos principais de implementação do padrão SAGA:

Orquestrado

Coreografado

🧰 Ferramentas para Design e Execução

Clean Architecture

🧱 O que é a Clean Architecture?

🌐 Camadas explicadas (de fora para dentro):

✅ Vantagens

⚠️ Desvantagens

#7 DP: Observer

O que é o Padrão Observer?

Exemplo:

#6 DP: Decorator

O que é o Padrão Decorator?

Exemplo prático

Sem o Decorator:

Vantagens do Decorator:

#5 DP: Adapter

O que é?

Exemplo:

#4 DP: Facade

O que é?

Exemplo

Configuração (`application.properties` / `application.yml`)