Methodologies

Escopo: transversal. Aplica-se a qualquer linguagem ou stack do projeto.

Metodologias definem como um time organiza o trabalho. Estilos arquiteturais definem como o código é estruturado e implantado. A escolha errada de qualquer um dos dois cobra seu preço cedo: retrabalho, rigidez ou complexidade desnecessária.

O código organiza-se em torno do domínio de negócio, não da infraestrutura. Os termos do negócio aparecem nos identificadores, nas classes e nas fronteiras do sistema, formando a Ubiquitous Language (Linguagem Ubíqua) entre engenheiros e especialistas de domínio.

Conceitos centrais:

Quando usar: sistemas com regras de negócio ricas e domínio complexo. Em CRUDs simples, o overhead de DDD supera o benefício.

Extensão do TDD com foco na linguagem de negócio. Cenários são escritos em formato Given / When / Then (Dado / Quando / Então), legível para stakeholders não-técnicos (partes interessadas sem perfil técnico).

Given um pedido com 3 itens
When o cliente aplica um cupom de 10%
Then o total deve refletir o desconto sobre o subtotal

O cenário vira o teste. A implementação serve o cenário.

Quando usar: features com critérios de aceite definidos por produto ou negócio; colaboração entre times técnicos e não-técnicos.

Ciclo de três fases: Red → Green → Refactor (Vermelho → Verde → Refatorar).

Red    → escrever o teste que falha (comportamento ainda não existe)
Green  → escrever o mínimo de código para o teste passar
Refactor → limpar o código sem quebrar os testes

O teste força o design por interface: você pensa em como vai usar antes de como vai implementar. O resultado é código com dependências explícitas e contratos claros.

Quando usar: qualquer sistema onde mudanças frequentes exigem confiança. Especialmente valioso em domínio de negócio com lógica de validação e regras de cálculo.

Conjunto de práticas de engenharia voltadas a feedback rápido e qualidade contínua:

XP é a base conceitual de práticas que hoje chamamos de DevOps e CI/CD (Continuous Integration and Continuous Delivery, Integração e Entrega Contínuas: CI é Integração Contínua; CD é Entrega Contínua).

Quando usar: times pequenos com entregas frequentes e domínio em evolução.

Tomada de decisão baseada em experiência acumulada, sem framework formal. O engenheiro escolhe por padrão reconhecido, não por processo definido.

Tem lugar válido:

Risco: difícil de justificar, transferir ou escalar para outras pessoas. Funciona bem como complemento a TDD: a intuição define a direção, o teste valida a chegada.

A estrutura emerge da necessidade real, sem planejamento upfront (antecipado) extenso. O código cresce na direção que o problema exige.

Não é ausência de disciplina: é adiamento deliberado de abstrações prematuras. A abstração aparece quando o padrão se repete três vezes (Rule of Three).

Risco: sem refactoring regular, dívida técnica se acumula silenciosamente. TDD como rede de segurança torna o desenvolvimento orgânico sustentável.

Anti-metodologia satírica. Premissa: "pensar é perda de tempo; commit primeiro".

Não é uma abordagem séria. É útil para nomear o que não fazer: código sem testes, sem revisão, sem fronteiras, com dependências ocultas e deploy por coragem.

Quando alguém descreve uma decisão técnica e você reconhece XGH, é um sinal de alerta.

Toda a aplicação em um único processo e deployável. O banco de dados, o servidor web e a lógica de negócio vivem juntos.

Vantagens: simples de desenvolver, depurar, testar e deployar. Uma única base de código, um único deploy, rastreamento direto de chamadas.

Quando o problema aparece: escalar um módulo obriga a escalar tudo. Acoplamento cresce com o time se não houver disciplina de fronteiras. Um bug pode derrubar o sistema inteiro.

Quando usar: início de projeto, times pequenos, domínio ainda sendo descoberto.

Serviços independentes, cada um com sua própria base de código, banco de dados e ciclo de deploy. Comunicam-se via API (Application Programming Interface, Interface de Programação de Aplicações) ou mensageria.

Vantagens: escala e evolui cada serviço de forma independente. Times diferentes ownam (são responsáveis por) serviços diferentes sem coordenação constante.

O custo real:

Quando usar: quando escala de time ou de domínio impõe isolamento real. Não como ponto de partida.

Módulos com fronteiras de domínio bem definidas dentro de um único processo. Cada módulo tem suas próprias camadas internas, expõe uma interface pública e não acessa diretamente os internos de outro módulo.

Monolito Modular
├── módulo: Orders
│   ├── domain/
│   ├── application/
│   └── api/ (interface pública do módulo)
├── módulo: Inventory
│   └── api/ (interface pública do módulo)
└── módulo: Billing
    └── api/ (interface pública do módulo)

Por que é o padrão recomendado em 2026:

Quando extrair um microsserviço: quando um módulo tem requisito de escala, ciclo de deploy ou equipe radicalmente diferentes dos demais. Não antes.

Metodologias

Estilos arquiteturais

Desenvolvido por @thiagocajadev · Fork baseado no repositório pmndrs/docs · Poimandres.