Trilha prática · Go

Regras de negócio que não dependem do banco, do framework ou do protocolo.

Aprenda Clean Architecture e Go ao mesmo tempo, evoluindo um único projeto real — aprovador-pedidos — camada por camada: domínio, casos de uso, interfaces e infraestrutura.

Partida
Zero em Go e em Clean Architecture
Destino
Ler e evoluir um projeto Go real
Prática
Projeto incremental único

Comece aqui

Aulas

  2. Aula 02 · 50–70 minutos

    Interfaces em Go

    Aula 2 — satisfação implícita, a convenção de onde declarar a interface, por que isso facilita testes, e a pegadinha do nil.

    Abrir aula

Como estudar esta trilha

31 aulas, um projeto só, evoluindo camada por camada

Cada aula parte de um problema concreto que já existe no projeto aprovador-pedidos — nunca de um exemplo abstrato solto. A ordem é deliberada: teoria (Regra de Dependência, DIP) antes da sintaxe de Go, sintaxe antes do primeiro projeto real, e cada camada nova (domínio, aplicação, infraestrutura, interface) só entra depois que a anterior está sólida. Aulas publicadas são clicáveis; as demais mostram a sequência planejada.

01 · Fundamentos

Entender por que a dependência aponta para dentro

Injeção de Dependência, Dependency Inversion Principle, a Regra de Dependência e as quatro camadas — antes de qualquer linha de Go.

  1. Módulos e pacotes em Go45–60 minutos · Aula 3 — go.mod, a relação entre diretório e pacote, caminhos de import, o diretório internal, e o que Go não dita sobre estrutura de pastas.
  2. Primeiro projeto Go real60–75 minutos · Aula 4 — construindo aprovador-pedidos do zero: domain puro, use case que declara a interface, fake para teste, implementação em memória e injeção manual em main.go.
  3. Screaming Architecture: o que a árvore de pastas deveria gritarEm breve

02 · Domínio

Dar estado e comportamento ao domínio

Um terceiro caso de uso revela que o domínio nunca teve estado explícito; Domain Events nomeia o que já acontecia escondido num adapter.

  1. Um terceiro use case: rejeitar, e o estado que faltavaEm breve
  2. Domain Events: nomeando o que pedido_eventos já fazia escondidoEm breve

03 · Aplicação

Modelar casos de uso e fronteiras

Um segundo caso de uso, DTOs nas fronteiras e a nomenclatura de Interactor/Input Boundary/Output Boundary de Uncle Bob comparada à do projeto.

  1. Um segundo use case: consultar pedidoEm breve
  2. DTOs: o que já existia desde a Lição 15, agora com nomeEm breve
  3. Input Ports: a nomenclatura de Uncle Bob vs. a do projetoEm breve

04 · Infraestrutura e persistência

Trocar detalhes sem tocar na regra

Banco de dados real, transações, configuração via variáveis de ambiente e um cliente de API externa — tudo isolado atrás de portas já definidas.

  1. Repositório real com banco de dadosEm breve
  2. Transações: duas escritas que precisam ser uma sóEm breve
  3. Configuração e variáveis de ambienteEm breve
  4. Integrando um cliente de API externa: score de crédito antes de aprovarEm breve

05 · Interface

Conectar o mundo externo ao caso de uso

Adapter HTTP, o roteador nativo do Go 1.22+, recuperação de panic e a diferença entre Presenter e DTO simples.

  1. Adapter HTTP para o caso de usoEm breve
  2. O roteador nativo do Go 1.22+Em breve
  3. panic e recover: o servidor não pode cair por um erro imprevistoEm breve
  4. Presenters e ViewModels: formatar não é decidirEm breve

06 · Testes e qualidade

Provar a regra, não só executá-la

Cross-cutting concerns via decorator, concorrência com goroutines e channels, testes tabulares e o ferramental que o time nunca discute.

  1. Cross-cutting concerns: logging sem sujar o use caseEm breve
  2. Goroutines e channels: consultando vários pedidos em paraleloEm breve
  3. Table-driven tests: um teste, muitos casosEm breve
  4. gofmt, go vet e linters: o time nunca discute chavesEm breve
  5. Conformidade arquitetural automatizadaEm breve

07 · Refatoração e evolução

Mudar um sistema vivo com risco controlado

SOLID e generics no projeto real, cancelamento com context, worker pools, coesão e acoplamento de componentes, evolução de contrato e CI/CD.

  1. SOLID no projeto real: S, O, L, IEm breve
  2. Generics: um decorator que serve para os três use casesEm breve
  3. context.Context: cancelamento atravessando as camadasEm breve
  4. Worker pool: limitando quantas goroutines rodam ao mesmo tempoEm breve
  5. Coesão e acoplamento de componentes: SOLID um nível acimaEm breve
  6. Evoluindo um use case sem quebrar contratoEm breve
  7. Extração de monolito modular: quando um pacote vira um móduloEm breve
  8. Consistência arquitetural em CI/CDEm breve

Para consultar

Referências rápidas

31 aulas planejadas · 4 publicadas.