Trilha prática · Go

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

Em progresso11/31 aulas

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 gritar50–70 minutos · Aula 5 — por que a estrutura de pastas de um projeto deveria comunicar o negócio, não o framework; aplicando a lente ao aprovador-pedidos e ao anti-padrão do pacote models genérico.

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 uma decisão que os casos de uso já tomavam silenciosamente.

  1. Um terceiro use case: rejeitar, e o estado que faltava50–70 minutos · Aula 6 — por que um bool não basta para representar o status de um pedido, o anti-padrão de dois bools independentes, e o tipo StatusPedido que torna o estado impossível irrepresentável.
  2. Domain Events: nomeando uma decisão que Executar já tomava escondida50–70 minutos · Aula 7 — por que uma decisão de negócio desaparecia ao virar só um novo valor de Status; o padrão Domain Event de Martin Fowler, os tipos PedidoAprovado e PedidoRejeitado, e main.go voltando a ser quem observa o que o domínio produziu.

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 pedido45–65 minutos · Aula 8 — o sistema só sabia escrever, nunca ler de volta; por que engordar PedidoRepository com Buscar viola o Interface Segregation Principle, e como PedidoFinder, uma interface pequena e separada, resolve isso.
  2. DTOs: o bug que Executar(domain.Pedido) escondia, e o padrão que já existia na Lição 455–75 minutos · Aula 9 — um bug real em AprovarPedido.Executar causado por receber domain.Pedido inteiro como parâmetro; a definição de DTO de Martin Fowler, seu próprio aviso contra usá-los sem necessidade, e o Input que corrige o bug sem contradizer esse aviso.
  3. Input Ports: a nomenclatura de Uncle Bob vs. a do projeto50–70 minutos · Aula 10 — nove aulas construindo Clean Architecture sem usar o vocabulário formal de Robert C. Martin (Interactor, Input/Output Boundary, Request/Response Model); o vocabulário irmão da Arquitetura Hexagonal (Port); e a peça que este projeto, de propósito, ainda não tem.

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 dados60–80 minutos · Aula 11 — memoria.PedidoRepository se aposenta; postgres.PedidoRepository entra em cena com pgx, ON CONFLICT DO UPDATE, e uma armadilha real do Go idiomático que violaria a Regra de Dependência se não fosse evitada de propósito.
  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 · 11 publicadas.