DEV Community: Matheus Kocotem

Arquitetura Hexagonal em Python do zero: um domínio que não sabe onde mora nem quem o chama

Matheus Kocotem — Wed, 16 Sep 2026 16:46:22 +0000

Durante muito tempo, a minha relação com "arquitetura" foi do tipo já ouvi falar. Sabia recitar que o domínio deve ser isolado, que regra de negócio não vai no controller, que acoplamento é ruim. Mas existe uma distância enorme entre repetir princípios e entender o que eles compram na prática e a única forma que conheço de atravessar essa distância é construir.

Então construí, do zero, uma aplicação Python inteira em arquitetura hexagonal para responder, com um exemplo real na mão, a uma pergunta simples: o que exatamente eu ganho isolando o domínio?

Este artigo é o registro dessa construção. Não é um tutorial de "cole esse comando"; é a explicação de por que cada peça existe. E ele gira em torno de duas provas concretas não de duas afirmações. Na primeira, um pedido gravado no PostgreSQL vai evaporar quando eu troco uma variável de ambiente. Na segunda, vou adicionar uma interface de linha de comando inteira ao sistema e mostrar, pelo histórico do Git, que o coração da aplicação não mudou uma única linha. Essas duas provas, juntas, são a arquitetura hexagonal inteira.

O que é arquitetura hexagonal, sem enrolação

A ideia, criada por Alistair Cockburn por volta de 2005, também atende pelo nome Ports & Adapters e esse nome descreve melhor o que ela é.

O domínio (as suas regras de negócio) fica no centro, isolado de qualquer framework. Ele não sabe se está sendo chamado por uma API REST ou por um terminal. Não sabe se seus dados vão parar em PostgreSQL ou num dicionário em memória. Para viver nessa bolha de ignorância feliz, o domínio declara portas interfaces que dizem "eu preciso de algo capaz de salvar um pedido" ou "me avise quando um pedido for pago", sem dizer onde nem como.

Quem responde às portas são os adaptadores. Um adaptador de entrada traduz uma requisição HTTP ou um comando de terminal numa chamada de caso de uso. Um adaptador de saída recebe o pedido "persista isso" e decide se grava num banco ou numa lista.

A regra que sustenta tudo tem uma direção: de fora para dentro. Os adaptadores conhecem o domínio; o domínio nunca conhece um adaptador. Quando essa seta aponta para o lado certo, tanto a borda de entrada quanto a de saída viram peças plugáveis.

        ADAPTADORES DE ENTRADA  (dois, mesma aplicação)
   ┌──────────────────────┐        ┌──────────────────────┐
   │  FastAPI (HTTP)      │        │   CLI (terminal)     │
   │  POST /orders ...    │        │   orders pay <id> ...│
   └──────────┬───────────┘        └───────────┬──────────┘
              └──────────────┬─────────────────┘
                             ▼ ambos chamam o mesmo
              ┌────────────────────────────────────┐
              │              PORTAS                │
              │        (Protocol do domínio)       │
              │   ┌────────────────────────────┐   │
              │   │         DOMÍNIO            │   │
              │   │  (zero import de framework)│   │
              │   │  Order, regras, desconto,  │   │
              │   │  estoque, expiração,       │   │
              │   │  eventos (OrderPaid)       │   │
              │   │  OrderService(casos de uso)│   │
              │   └────────────────────────────┘   │
              │  OrderRepository · NotificationPort│
              │  StockPort · Clock                 │
              └───────────────┬────────────────────┘
                              │ implementado por
        ┌─────────────┬───────┴───────┬──────────────┐
        ▼             ▼               ▼              ▼
   InMemoryRepo  SqlAlchemyRepo  Logging/Memory   MemoryStock
                                 Notification
              ADAPTADORES DE SAÍDA

Guarde esse desenho. O resto do artigo é ele ganhando vida e depois sendo estressado.

O domínio: o único lugar que importa

Escolhi um caso pequeno mas com regra de verdade: gestão de pedidos. E a primeira regra que impus a mim mesmo foi radical: nada em domain/ pode importar um framework. Nenhum import fastapi, nenhum import sqlalchemy, nenhum import pydantic. Se você abrir um arquivo do domínio e vir o nome de uma tecnologia, algo já deu errado.

A entidade Order é uma dataclass de Python puro. Repare no total:

@property
def total(self) -> Decimal:
    subtotal = sum((item.subtotal for item in self.items), Decimal("0"))
    return subtotal discount_for(subtotal)

O total não é um campo que alguém preenche é uma propriedade derivada, recalculada sempre a partir dos itens e da política de desconto. É impossível um pedido existir com um total que não bate com seu conteúdo. O cliente da API pode mandar o total que quiser no corpo da requisição: vai ser solenemente ignorado, porque quem manda no total é o domínio, não a rede.

As regras ficam junto da entidade, protegendo o estado:

def pay(self) -> None:
    if self.status is not OrderStatus.PENDING:
        raise OrderError("Só é possível pagar um pedido PENDING")
    self.status = OrderStatus.PAID
    self._events.append(OrderPaid(order_id=self.id))

Um pedido só é pago se estiver pendente; um pago não se cancela; um pendente velho demais vira EXPIRED. E, ao ser pago, o pedido registra um evento numa lista interna guarde isso, porque é assim que a notificação vai acontecer sem o domínio jamais conhecer quem notifica.

Um detalhe de disciplina que vale destacar: a expiração é um caso de uso expire_stale_orders(now, max_age) que recebe o "agora" como parâmetro. Nada de datetime.now() escondido dentro do domínio. Isso mantém o núcleo determinístico e testável você testa "expirou depois de 24h" passando um relógio de mentira, sem esperar 24 horas nem depender do relógio da máquina. O tempo, aqui, também entra por uma porta (Clock).

As portas: contratos que o domínio dita

Aqui está o detalhe que torna isso especialmente elegante em Python. As portas são typing.Protocol:

class OrderRepository(Protocol):
    def save(self, order: Order) -> None: ...
    def get_by_id(self, order_id: str) -> Order | None: ...
    def list_all(self, limit: int, offset: int) -> list[Order]: ...

Em Java, uma porta é uma interface e o adaptador declara implements. Em Python, com Protocol, o encaixe é estrutural: qualquer classe com esses métodos e assinaturas já é um OrderRepository, sem herdar de nada. O domínio define a forma da tomada; o adaptador só precisa ter o formato do plugue.

Parece frouxo "e se eu errar uma assinatura?". Não é: rodo mypy --strict, e é o verificador de tipos que confirma, antes de o código rodar, que cada adaptador satisfaz sua porta. No projeto final, o mypy strict passa limpo em 25 arquivos. Uma assinatura incompatível num adaptador seria pega ali, estaticamente sem herança e sem precisar subir um banco para descobrir.

Os casos de uso: orquestração sem tecnologia

OrderService é onde os casos de uso vivem, e ele depende só das portas:

class OrderService:
    def __init__(
        self,
        repository: OrderRepository,
        notifications: NotificationPort,
        stock: StockPort,
        clock: Clock,
    ) -> None:
        ...

    def pay_order(self, order_id: str) -> Order:
        order = self._require(order_id)
        order.pay()
        self._repository.save(order)
        for event in order.pull_events():      # drena OrderPaid
            self._notifications.notify_order_paid(order)
        return order

Olhe o pay_order: ele paga, persiste, drena os eventos que a entidade registrou e despacha a notificação tudo através de portas. O serviço nunca importa um adaptador concreto. Ele não sabe se a notificação vira um log, um e-mail ou uma mensagem numa fila. Sabe só que existe uma NotificationPort e que ela precisa ser avisada.

Isso foi verificado de verdade: rodando em Docker, o pagamento de um pedido produziu um log real do adaptador concretonotification.order_paid disparado sem que OrderService conhecesse esse adaptador. E, no teste de caso de uso, injeto uma NotificationPort de mentira que guarda as notificações numa lista, e afirmo o comportamento com precisão: pagar notifica exatamente uma vez; cancelar notifica zero.

Prova nº 1: o pedido que evaporou

Para o domínio, "onde os dados moram" é indiferente. Escrevi dois adaptadores de persistência para a mesma porta OrderRepository: um dicionário em memória (dezenas de linhas, zero dependências) e uma implementação real com SQLAlchemy sobre PostgreSQL, com o mapeamento de tabelas vivendo em orm.py, fora do domínio.

Quem escolhe qual usar? Um único arquivo a composition root, composition.py lendo a config:

def build_repository(settings: Settings) -> OrderRepository:
    if settings.repository == "postgres":
        return SqlAlchemyOrderRepository(settings.database_url)
    return InMemoryOrderRepository()

Subi tudo com Docker (API + Postgres real, com Alembic aplicando o schema no start). Criei um pedido via curl; foi para o Postgres. Para confirmar persistência de verdade, reiniciei o container da aplicação o pedido continuava lá. Paguei; tentei cancelar em seguida e recebi 409 Conflict, exatamente como a regra manda.

Então subi a mesma aplicação trocando uma variável:

REPOSITORY=memory docker compose up app

Busquei o pedido pelo id. 404 Not Found. Evaporou.

E isso é uma boa notícia. Não é bug: com REPOSITORY=memory, a aplicação fala com um armazenamento genuinamente diferente, um dicionário vazio na memória do processo. O pedido segue vivo no Postgres; a aplicação é que não olha mais para lá. Troquei a tecnologia de persistência inteira de banco relacional para memória volátil sem tocar uma linha de domain/ ou services.py. O núcleo nunca soube que foi trocado. É esse não-saber que é o objetivo.

Prova nº 2: a interface que não mexeu no coração

A troca do banco prova metade do teorema que a borda de saída é plugável. Faltava a outra metade: a borda de entrada.

Então adicionei um segundo adaptador de entrada. Além da API FastAPI, o mesmo sistema agora tem uma CLI dá para criar, pagar, cancelar e listar pedidos pelo terminal. E o ponto não é "que legal, tem CLI". O ponto é como ela foi adicionada.

A CLI reaproveita build_order_service() a mesmíssima composição que a API usa. Ela é só mais um adaptador traduzindo entrada (argumentos de terminal, em vez de JSON HTTP) em chamadas do mesmo OrderService. Nenhuma regra foi reescrita. Nenhuma regra foi copiada.

E aqui está a prova que eu mais gosto neste projeto, porque não depende da minha palavra. Isolei a adição da CLI num único commit. O git diff --stat desse commit:

 app/adapters/inbound/cli.py | 118 +++++++++++++++++++++++
 tests/test_cli.py           |  64 +++++++++++++
 2 files changed, 182 insertions(+)

Dois arquivos. O adaptador novo e seu teste. Zero linhas alteradas em app/domain/. Zero em services.py. O sistema ganhou uma forma inteiramente nova de ser operado, e o coração dele não sentiu. Isso é a arquitetura hexagonal deixando de ser um slogan e virando uma linha de git diff que qualquer pessoa pode conferir.

Duas provas, uma simetria: a saída troca sem tocar no núcleo (o pedido evaporou), e a entrada se multiplica sem tocar no núcleo (o commit da CLI). O domínio não sabe onde mora, nem quem o chama.

O bônus que só a separação permite: testes que voam

Manter o domínio puro tem um efeito colateral delicioso nos testes. O projeto tem 53 testes, divididos assim:

domain      -> 21 testes, Python puro
use_cases   -> 13 testes, OrderService + adaptadores em memória
api         -> 10 testes, FastAPI TestClient
cli         ->  5 testes, o segundo adaptador de entrada
sqlalchemy  ->  4 testes de integração (só estes pedem Postgres)

Os 34 testes de domínio e casos de uso rodam sem subir servidor nem banco, porque dependem só do domínio puro e de adaptadores em memória que são adaptadores legítimos das mesmas portas. Você não precisa de um Postgres de pé para testar "pedido pago não se cancela", porque essa regra não tem nada a ver com Postgres. No modo padrão de desenvolvimento, os 4 testes de integração são pulados automaticamente quando não há banco configurado; o CI, esse sim, sobe um Postgres real e roda os 53. A mesma arquitetura que isola o domínio para trocar o banco é a que deixa você testar o domínio sem banco nenhum.

Os detalhes que só a prática ensina

Além da teoria, construir isso me ensinou coisas que não aparecem nos diagramas:

Pydantic não é o seu domínio. O erro mais comum ao "fingir" hexagonal com FastAPI é usar o modelo Pydantic como entidade de negócio. Mantive os schemas Pydantic (validação/serialização HTTP) separados da dataclass Order (regra de negócio). Fundir os dois é abrir um furo por onde a web vaza para dentro do núcleo.

Traduza erros de domínio num só lugar. As exceções do domínio não sabem o que é status HTTP nem deveriam. Um único ponto em api.py traduz OrderError/OrderNotFoundError em 409/404. Uma ponte de vocabulário, num lugar só.

Alembic tem uma armadilha clássica. Ao gerar a migration por autogenerate contra o Postgres, o downgrade não removia o tipo enum criado — o famoso bug de enum órfão. Corrigi e testei o roundtrip completo (upgrade → downgrade → upgrade). É o tipo de detalhe que só aparece quando você roda de verdade, não quando lê sobre.

O tempo é uma dependência. Tratar now como algo que entra por uma porta (Clock), em vez de chamar datetime.now() no meio da regra, foi o que tornou a expiração testável sem hacks.

Conclusão

No fim, a sensação é quase decepcionante de tão tranquila: você muda REPOSITORY, sobe a aplicação, e o sistema fala com outro banco sem reclamar. Você adiciona uma CLI inteira, e o git diff do domínio vem vazio.

Mas essa tranquilidade é o produto. Toda a disciplina — o domínio sem imports de framework, as portas como Protocol, os adaptadores plugáveis dos dois lados, o composition root isolado existe para que as decisões de tecnologia deixem de ser casamentos e virem o que deveriam ser: peças plugáveis na borda, trocáveis sem medo.

O sistema completo tem bastante coisa de projeto sério que este artigo nem detalhou — migrations versionadas com Alembic, configuração via pydantic-settings, logging estruturado em JSON, health check que testa o banco, paginação, métricas opcionais e um CI que roda lint, type-check estrito e os 53 testes contra um Postgres real. Mas nada disso é o ponto. O ponto são as duas linhas de prova: um pedido que some de propósito, e um commit que não toca no coração.

Construir o encaixe é o trabalho difícil. Trocar a peça encaixada de qualquer lado é o que fica fácil. E eu quis construir o encaixe.

Se você também está tentando sair do "já ouvi falar" para o "entendi de verdade", o conselho é o de sempre: não leia só, construa. Porta, adaptador e inversão de dependência param de ser abstrações no exato momento em que você vê um pedido evaporar do banco de propósito, sem medo e confere, no histórico do Git, que dar ao sistema uma boca nova não exigiu mexer no seu coração.

O código completo, pronto para rodar com docker compose up, está no repositório.

Construindo uma plataforma GitOps do zero: Kubernetes, ArgoCD, Terraform e Observabilidade

Matheus Kocotem — Mon, 27 Jul 2026 22:53:33 +0000

Durante muito tempo, meu contato com Kubernetes foi do tipo "já mexi": subi um pod aqui, apliquei um manifesto ali, vi um deploy acontecer. Mas existe uma distância enorme entre usar uma ferramenta e entender o que ela faz por baixo. Eu venho de backend Java e automação de testes, e decidi atravessar essa distância de propósito construindo, do zero, uma plataforma GitOps completa e local.

Este artigo é o registro dessa construção. Não é um tutorial de "cole esse comando"; é uma explicação de por que cada peça existe e como elas se encaixam. Ao final, você terá visto uma infraestrutura nascer de um único comando, deploys acontecerem a partir de um git push, e métricas de uma aplicação Java fluírem até um dashboard tudo versionado, tudo reproduzível.

O que vamos construir

Antes do código, o mapa mental. A plataforma tem quatro camadas que se encaixam.

O Terraform provisiona o cluster e instala o motor de GitOps. É a fundação como código.

O kind roda um cluster Kubernetes real dentro de containers Docker, localmente.

O ArgoCD observa um repositório Git e garante que o cluster reflita exatamente o que está versionado.

Por fim, Prometheus e Grafana coletam e visualizam métricas, incluindo métricas customizadas de uma API Spring Boot.

O fio que costura tudo é uma ideia só: o Git é a fonte da verdade. Você não muda o cluster na mão; você muda arquivos no Git, e o cluster se ajusta.

Por que GitOps?

Vale parar um instante nessa ideia, porque ela é o coração de tudo.

No modelo tradicional, você aplica mudanças no cluster diretamente — um kubectl apply aqui, um kubectl scale ali. O problema é que o cluster vira uma caixa-preta. Ninguém sabe ao certo por que ele está do jeito que está, quem mudou o quê ou como reproduzir aquele estado em outro ambiente.

GitOps inverte isso. O estado desejado do cluster vive num repositório Git. Uma ferramenta (aqui, o ArgoCD) fica continuamente comparando o que deveria estar rodando (o Git) com o que está rodando (o cluster) e corrige qualquer diferença.

Na prática, isso significa que toda mudança passa a ter auditoria automática, porque ela é registrada como um commit com autor, data e motivo. Também significa que qualquer ambiente pode ser reproduzido a partir do mesmo repositório, que voltar atrás é tão simples quanto executar um git revert e que ninguém precisa de acesso direto ao cluster para fazer deploy: basta commitar.

Guarde essa ideia, porque vamos vê-la acontecer na prática.

Camada 1: o cluster como código com Terraform

O primeiro instinto de quem começa é criar o cluster na mão. O comando existe e é simples. Mas isso já quebra a promessa da reprodutibilidade — amanhã você não lembra exatamente como criou.

Por isso, desde o início, o cluster nasce de Terraform. O trecho central declara três providers e o cluster:

terraform {
  required_providers {
    kind       = { source = "tehcyx/kind", version = "~> 0.9" }
    helm       = { source = "hashicorp/helm", version = "~> 2.17" }
    kubernetes = { source = "hashicorp/kubernetes", version = "~> 2.35" }
  }
}

resource "kind_cluster" "this" {
  name           = "gitops-lab"
  wait_for_ready = true

  kind_config {
    kind        = "Cluster"
    api_version = "kind.x-k8s.io/v1alpha4"

    node { role = "control-plane" }
    node { role = "worker" }
    node { role = "worker" }
  }
}

Repare em duas decisões. Primeiro, o cluster tem três nós (um control-plane e dois workers) em vez de um só. Isso não é firula: com múltiplos nós, você vê o Kubernetes distribuir cargas entre eles, o que torna conceitos como alta disponibilidade concretos em vez de teóricos.

Segundo, as versões dos providers estão fixadas. Isso é o que garante que um terraform apply daqui a seis meses produza o mesmo resultado de hoje. Reprodutibilidade não é acidente; é uma escolha.

A partir daí, o mesmo Terraform instala o ArgoCD via Helm, já apontando os providers para o cluster recém-criado. Um único terraform apply entrega o cluster e o motor de GitOps prontos.

Camada 2: ensinando o ArgoCD a observar o Git

Com o ArgoCD instalado, ele está de pé, mas ocioso — não sabe o que observar. É preciso apresentá-lo a um repositório. Isso se faz com um objeto chamado Application.

A Application é a ponte. Ela diz três coisas: de onde puxar, para onde aplicar e como se comportar.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/usuario/gitops-manifests.git
    targetRevision: main
    path: apps/nginx
  destination:
    server: https://kubernetes.default.svc
    namespace: nginx-demo
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

As duas linhas mais importantes deste arquivo são prune: true e selfHeal: true. Elas são o que torna o GitOps realmente vivo.

Com selfHeal, se alguém alterar o cluster manualmente, o ArgoCD detecta a divergência em relação ao Git e desfaz a mudança. O Git vence.

Já prune garante que, se um recurso for removido do repositório, ele também será removido do cluster. O cluster espelha exatamente o conteúdo do Git, nada mais.

O momento GitOps: escalar com um commit

Aqui a teoria vira prática, e é o momento que fixa o conceito.

Com o nginx rodando com uma réplica, fiz uma mudança que normalmente exigiria um comando no cluster: aumentar para três réplicas. Só que, em GitOps, isso não é um comando. É uma edição de arquivo:

spec:
  replicas: 3   # antes era 1

Um git commit e um git push depois, o ArgoCD detectou a diferença e criou dois novos pods — sozinho. Eu nunca rodei kubectl scale. O cluster simplesmente convergiu para o que o Git passou a dizer.

O teste que mais ensina veio a seguir. Executei um kubectl scale manual, forçando o cluster de volta a uma réplica. Por um instante, os pods começaram a ser removidos. Então o selfHeal entrou em ação: o ArgoCD percebeu que o cluster havia divergido do Git, que ainda dizia três réplicas, e recriou automaticamente os pods. Minha alteração manual foi desfeita em poucos segundos.

Essa é a garantia que dá segurança a ambientes de produção reais: não existe "conserta rápido no cluster e esquece". Toda mudança passa pelo Git ou acaba sendo revertida.

Camada 3: observabilidade e o diferencial da métrica de negócio

Uma plataforma que você não consegue enxergar é uma plataforma que você não controla. Por isso a última camada é observabilidade.

Instalei o kube-prometheus-stack, um pacote que traz Prometheus, Grafana e Alertmanager já integrados, mantendo o padrão GitOps: ele entra no cluster como mais uma Application do ArgoCD.

Um detalhe técnico importante aqui é que charts Helm muito grandes, como esse, exigem a opção ServerSideApply=true no ArgoCD, porque seus CRDs ultrapassam o limite de tamanho da aplicação tradicional. É o tipo de detalhe que normalmente só aparece durante a prática.

Mas coletar métricas genéricas de CPU e memória é apenas o básico. O que realmente diferencia uma plataforma é medir lógica de negócio. E foi aqui que meu background em Java entrou como vantagem.

Criei uma API Spring Boot simples que expõe uma métrica customizada: um contador que incrementa a cada chamada de um endpoint.

@RestController
public class HelloController {
    private final Counter helloCounter;

    public HelloController(MeterRegistry registry) {
        this.helloCounter = Counter.builder("demo_hello_requests_total")
                .description("Total de chamadas ao endpoint /hello")
                .register(registry);
    }

    @GetMapping("/hello")
    public String hello() {
        helloCounter.increment();
        return "Olá do GitOps Lab!";
    }
}

Com Spring Boot Actuator e Micrometer, expor essa métrica no formato que o Prometheus entende exige muito pouca configuração.

A ponte final entre a aplicação e o Prometheus é um recurso chamado ServiceMonitor, responsável por informar ao Prometheus quais pods devem ser monitorados. Existe, porém, um detalhe que costuma bloquear muita gente: o ServiceMonitor precisa possuir um label específico (release: monitoring) para ser descoberto pelo Prometheus. Sem esse label, a coleta simplesmente não acontece e, pior, não existe uma mensagem de erro evidente indicando o motivo.

Com tudo conectado, o fluxo finalmente se fecha. Cada chamada ao endpoint incrementa o contador, o Prometheus coleta esse valor periodicamente e o Grafana o exibe em tempo real. Pela primeira vez, vi uma métrica escrita por mim, em Java, aparecer em um dashboard.

Houve ainda um detalhe interessante: o gráfico mostrava duas séries diferentes, uma para cada pod, com valores distintos. Não era um bug. Era o balanceamento de carga do Kubernetes se tornando visível através das métricas, mostrando que o tráfego estava sendo distribuído de forma desigual entre as instâncias da aplicação.

Os detalhes que só a prática ensina

Se eu tivesse que resumir o valor de construir tudo isso manualmente, em vez de apenas ler sobre o assunto, seria nos detalhes que dificilmente aparecem em diagramas.

Descobri que imagens carregadas localmente no kind exigem imagePullPolicy: IfNotPresent; caso contrário, o Kubernetes tentará buscá-las em um registry remoto e falhará.

Também percebi que separar o repositório de infraestrutura do repositório de manifestos evita acoplar mudanças na plataforma aos deploys das aplicações, permitindo que cada um siga seu próprio ciclo de vida.

E, talvez o hábito mais importante de todos, aprendi que ler cuidadosamente o resultado de um terraform plan antes do terraform apply é a diferença entre operar com confiança e simplesmente torcer para que tudo funcione.

Conclusão

No fim, a sensação é quase decepcionante de tão tranquila: você muda um número no Git, faz um git push e o cluster inteiro se ajusta sozinho.

Mas essa simplicidade aparente é justamente o objetivo. Uma boa plataforma esconde a complexidade atrás de um simples git push. Toda a engenharia — o cluster multi-nó, os componentes do ArgoCD conversando entre si, a reconciliação contínua e toda a cadeia de observabilidade — existe para que operar seja simples. Construir a transmissão automática é difícil; dirigir um carro automático é fácil. Eu quis construir a transmissão.

Se você também está atravessando a jornada de backend para plataforma, meu conselho é simples: não leia apenas. Construa. Conceitos como reconciliação, estado desejado e fonte da verdade deixam de ser abstratos no momento em que você vê o ArgoCD desfazer uma alteração manual e restaurar exatamente o que o Git determina.

O código completo, com instruções para executar tudo do zero, está disponível no repositório. E este é apenas o começo: os próximos capítulos incluem alertas, um pipeline de validação de manifestos e a migração para uma cloud gerenciada.

Até a próxima.