Domain-Driven Design (DDD) e uma abordagem de desenvolvimento de software que prioriza a modelagem do dominio de negocio como o centro da arquitetura. Proposto por Eric Evans em 2003, DDD e especialmente valioso para sistemas complexos onde a logica de negocio e intrincada. Em 2026, e adotado por times em empresas como Nubank, Stone, iFood e outras.
Quando usar DDD
DDD faz sentido quando: o dominio de negocio e complexo (regras intrincadas, muitos casos de borda), a equipe trabalha proximo a especialistas de negocio, o software vai evoluir por muitos anos, a complexidade esta no negocio e nao na tecnica.
DDD NAO faz sentido para: CRUDs simples, projetos de curta duracao, prototipos e MVPs iniciais, quando nao ha acesso a especialistas de negocio.
Linguagem Ubiqua (Ubiquitous Language)
O conceito mais importante do DDD — e nao e tecnico. E criar um vocabulario compartilhado entre devs e especialistas de negocio. Se o negocio fala “Pedido”, o codigo tem uma classe Pedido (nao Order, nao Request). Se o negocio diz “Cancelar pedido”, o metodo e pedido.cancelar() (nao pedido.set_status(“cancelled”) ou pedido.update(active=false)).
A linguagem ubiqua garante que o codigo reflete o negocio. Discussoes sobre o software usam os mesmos termos que discussoes sobre o negocio. Nao ha traduccao mental.
Building blocks do DDD
Entity (Entidade)
Objeto com identidade unica que persiste ao longo do tempo. Dois objetos com os mesmos atributos mas IDs diferentes sao entidades diferentes.
class Pedido:
def __init__(self, id, cliente, itens):
self.id = id
self.cliente = cliente
self.itens = itens
self.status = StatusPedido.CRIADO
self.data_criacao = datetime.now()
def confirmar(self):
if self.status != StatusPedido.CRIADO:
raise PedidoNaoPodeSerConfirmado(self.id, self.status)
if not self.itens:
raise PedidoSemItens(self.id)
self.status = StatusPedido.CONFIRMADO
Note: a logica de negocio esta na entidade. Nao em um servico separado que manipula o estado do pedido de fora.
Value Object (Objeto de Valor)
Objeto sem identidade propria, definido pelos seus atributos. Dois objetos de valor com os mesmos atributos sao iguais. Deve ser imutavel.
@dataclass(frozen=True)
class Endereco:
rua: str
numero: str
cidade: str
estado: str
cep: str
@dataclass(frozen=True)
class Dinheiro:
valor: Decimal
moeda: str = “BRL”
def __add__(self, outro):
if self.moeda != outro.moeda:
raise MoedasDiferentes(self.moeda, outro.moeda)
return Dinheiro(self.valor + outro.valor, self.moeda)
Aggregate (Agregado)
Cluster de entidades e value objects tratados como uma unidade para mudancas de dados. Toda modificacao passa pela raiz do agregado. O Pedido e a raiz do agregado que contem ItemPedido. Voce nunca modifica um ItemPedido diretamente — sempre atraves do Pedido (pedido.adicionar_item(), pedido.remover_item()).
Repository
Abstrai o acesso ao banco de dados. Cada agregado tem um Repository. O repositorio fala a linguagem do dominio: PedidoRepository.buscar_pendentes_por_cliente(cliente_id) — nao repositorio.query(“SELECT * FROM pedidos WHERE status = …”).
Domain Service
Logica de negocio que nao pertence a uma entidade especifica. Envolve multiplas entidades ou agregados.
class TransferenciaService:
def transferir(self, conta_origem, conta_destino, valor):
if conta_origem.saldo < valor:
raise SaldoInsuficiente(conta_origem.id, conta_origem.saldo, valor)
conta_origem.debitar(valor)
conta_destino.creditar(valor)
Bounded Context (Contexto Delimitado)
Em sistemas grandes, diferentes partes do negocio podem ter significados diferentes para o mesmo termo. “Cliente” no contexto de Vendas e diferente de “Cliente” no contexto de Suporte.
Bounded Context e o limite onde um modelo de dominio e valido. Cada BC tem sua propria linguagem ubiqua, seus proprios models, seus proprios repositorios. A comunicacao entre BCs acontece via integration events ou APIs.
DDD e Microservicos
Cada Bounded Context e um candidato natural a microservico. O BC de Vendas vira o Servico de Vendas. O BC de Pagamentos vira o Servico de Pagamentos. A comunicacao entre eles via eventos (EDA) ou APIs mantem o desacoplamento.
A combinacao DDD + Event-Driven Architecture + Microservicos e a arquitetura moderna mais robusta para sistemas complexos em 2026.
Tem um projeto em mente?
Somos especialistas em transformar ideias em produtos digitais. Apps, sites, automações e IA — vamos construir juntos.
