Glossário — Clean Architecture com Go
Termos usados nas lições de Clean Architecture com Go, na ordem em que aparecem. Cresce a cada lição nova.
Clean Architecture
Estilo de arquitetura de software proposto por Robert C. Martin (Uncle Bob) em que o código é organizado em camadas concêntricas, e as regras de negócio ficam isoladas de detalhes técnicos (banco de dados, frameworks, UI). O objetivo é um sistema testável e fácil de mudar, porque os detalhes dependem das regras de negócio — nunca o contrário.
Fonte: The Clean Architecture, Robert C. Martin (2012).
Injeção de Dependência (Dependency Injection)
Técnica em que uma função ou tipo recebe suas dependências prontas de fora (por parâmetro ou construtor), em vez de criá-las internamente. Termo cunhado por Martin Fowler em 2004. É o mecanismo concreto que torna o Dependency Inversion Principle possível na prática — sem DI, não há como uma implementação externa "entrar" numa peça de código que segue a Regra de Dependência.
Fonte: Inversion of Control Containers and the Dependency Injection pattern, Martin Fowler (2004).
Regra de Dependência (Dependency Rule)
O princípio central da Clean Architecture: dependências de código-fonte só podem apontar para dentro, em direção às políticas de mais alto nível. Nada em um círculo interno pode saber algo sobre um círculo externo — nem o nome de uma função, tipo, ou qualquer detalhe de uma camada mais externa. É o Dependency Inversion Principle aplicado sistematicamente a um projeto inteiro, camada por camada.
Dependency Inversion Principle — DIP (Inversão de Dependência)
O "D" do SOLID. Princípio sobre a direção da dependência entre módulos, com duas partes: (1) módulos de alto nível não devem depender de módulos de baixo nível — ambos devem depender de abstrações; (2) abstrações não devem depender de detalhes — detalhes devem depender de abstrações. Diferente de Injeção de Dependência (a técnica): DIP é o princípio — quem deveria depender de quem; DI é o mecanismo — como a implementação chega até quem precisa dela.
Fonte: Design Principles and Design Patterns, Robert C. Martin (2000) — mesmo autor de "The Clean Architecture". O acrônimo SOLID foi cunhado depois, por Michael Feathers.
Entities (Entidades / Domínio)
A camada mais interna. Contém as regras de negócio mais gerais e estáveis do sistema — o que a empresa faria independente de ter software ou não. Não sabe nada sobre banco de dados, HTTP, ou qualquer framework.
Use Cases (Casos de Uso / Aplicação)
Orquestram o fluxo de dados entre as entidades para realizar uma tarefa específica do sistema (ex: "aprovar um pedido"). Contêm as regras de negócio específicas da aplicação, mas ainda não sabem como os dados chegam ou para onde vão.
Interface Adapters
Convertem dados entre o formato mais conveniente para os use cases/entities e o formato mais conveniente para agentes externos (banco de dados, web, etc.). Exemplos: controllers, presenters, gateways.
Frameworks & Drivers
A camada mais externa: banco de dados, framework web, ferramentas de UI. É onde ficam os detalhes técnicos — a camada mais fácil de trocar, porque nada de dentro depende dela.
Hexagonal Architecture (Ports & Adapters)
Arquitetura publicada por Alistair Cockburn em 2005 — anterior à Clean Architecture e citada como uma de suas influências. A ideia central é a mesma: a aplicação (o "hexágono") não conhece o mundo externo diretamente, só através de portas (interfaces que ela define) e adapters (implementações concretas plugadas nessas portas) — o mesmo papel que os Interface Adapters cumprem na Clean Architecture. É o nome mais usado no mercado para esse mesmo conjunto de ideias.
Fonte: Hexagonal Architecture, Alistair Cockburn (2005).
Struct
Tipo concreto em Go que agrupa dados: uma lista de campos nomeados, cada um com um tipo. Não tem comportamento próprio até que métodos sejam declarados para ela. Análogo a uma classe só com atributos, ou a um record/"data class" de outras linguagens.
Interface (Go)
Tipo em Go que agrupa comportamento: uma lista de assinaturas de métodos, sem nenhum dado próprio. Um contrato — o mesmo conceito de interface de outras linguagens orientadas a objetos, com uma diferença: em Go, ela é satisfeita por satisfação implícita, não por declaração explícita.
Satisfação implícita (Implicit Interface Satisfaction)
Mecanismo de Go em que um tipo satisfaz uma interface apenas por ter os métodos que ela exige, sem nenhuma declaração explícita (não existe palavra-chave implements). O compilador confere a satisfação estruturalmente, no ponto de uso. Isso permite que o pacote que implementa uma interface nem precise importar o pacote que a declara. Convenção associada: em Go, a interface deveria ser declarada no pacote que a usa, não no pacote que a implementa — é a Regra de Dependência expressa em pacotes.
Fonte: The Go Programming Language Specification — Interface types; Go Code Review Comments.
Módulo (Go module)
Unidade de versionamento e distribuição de código em Go — na prática, o projeto inteiro. Declarado por um único arquivo go.mod na raiz, que fixa o caminho canônico de importação (module path) e a versão mínima de Go exigida. Análogo ao package.json (Node) ou ao composer.json (PHP), com uma diferença: em Go, esse caminho também funciona como prefixo de import para todo pacote do módulo.
Fonte: Go Modules: Package and Module Layout.
Pacote (Go package)
Unidade de organização de código dentro de um módulo: cada diretório com arquivos .go é um pacote, e todo arquivo nesse diretório compartilha o mesmo package declarado no topo. Um módulo normalmente contém múltiplos pacotes — um por diretório —, mas um pacote nunca atravessa módulos. O caminho de import (module path + caminho da pasta) é o que fisicamente restringe o que um pacote pode acessar de outro: sem a linha de import, não há acesso possível. É a base física da Regra de Dependência em projetos Go.
Fonte: Go Modules: Package and Module Layout.
internal (diretório especial)
Convenção reforçada pelo próprio compilador do Go: qualquer pacote dentro de uma pasta chamada internal só pode ser importado por código do mesmo módulo, a partir do diretório pai de internal. Usado para impedir que outros módulos dependam de pacotes que o projeto não quer expor como API pública — mesmo em repositórios públicos. Não é uma camada da Clean Architecture; é um mecanismo de visibilidade do Go, ortogonal às camadas.