Domain-Driven Design

O modelo é o software. Linguagem ubíqua no código. DDD não é pastas Domain/ com getters — é invariantes protegidas por agregados e contextos com limites claros.

Escolha de estilo: software-architecture. Setas de dependência: clean-architecture. Um deploy, vários contextos: modular-monolith. Extração: microservices-architecture.

Quando (não) usar

Use quando regras, conflitos de linguagem e ciclos de vida de dado forem o risco.

Não use (tático pesado) em CRUD, BFF fino, jobs de glue. Ali, transações simples e DTOs bastam. Strategic (nomes de contexto) ainda ajuda.

Estratégico

Linguagem ubíqua

• Os termos do domínio aparecem em tipos, métodos e eventos — não ManagerUtil, DataDTO2.
• Se o negócio diz “reserva” e o código diz “OrderItemFlag`, o modelo está errado.
• Glossário curto por contexto; o mesmo termo não significa a mesma coisa em outro contexto (Pagamento ≠ Fatura).