Seu sistema não é orientado a objetos. É orientado a dados.
Uma conversa franca sobre como pensar software na vida real: com DDD, boas práticas de código e arquitetura limpa.
Imagine a cena: sexta-feira de Black Friday, o checkout da loja cai. Ninguém no time pergunta “onde está o OrderService?”. A pergunta real é: “cadê os dados do pedido, do pagamento e da entrega?”. O usuário não está nem aí para suas classes elegantes ou para seu framework da moda — ele só quer saber se a compra foi registrada, paga e vai chegar. O que realmente conecta todo o fluxo de negócio são os dados e os eventos que registram cada passo da jornada.
Um pedido 78412, por exemplo, atravessa carrinho, antifraude, pagamento, faturamento e logística. Ao longo do caminho, APIs mudam, classes são refatoradas, times reestruturados. Mas a história desse pedido continua viva porque ficou gravada em dados: quando foi confirmado, quando o pagamento foi aprovado, quando a nota fiscal foi emitida, quando foi despachado. O fio condutor não são objetos de código: são eventos e registros que contam uma história coerente.
Essa é a provocação central deste artigo: seu sistema pode ter nascido em orientação a objetos, mas na prática sobrevive porque é, e sempre foi, orientado a dados.
O que significa “orientado a dados” (sem dogma)
Antes de mais nada: não é sobre jogar fora orientação a objetos. Objetos ainda são ótimos para organizar comportamento, encapsular regras e dar clareza ao código. Mas a cola que mantém o sistema vivo são os dados com significado: informações que contam uma história, viajam entre sistemas e precisam sobreviver às trocas de frameworks e linguagens.
Pense assim:
OO organiza comportamento e estado em objetos.
DDD organiza o significado: nomes claros, contextos delimitados, agregados que guardam invariantes.
Arquitetura limpa organiza as dependências: regras de negócio no centro, detalhes de persistência e frameworks na periferia.
Traduzindo para a vida real: primeiro vem o vocabulário (como chamamos as coisas e quais campos importam), depois os limites (quem é responsável por cada pedaço de informação), e só então os mecanismos (banco, API, mensageria). O problema é que muita gente inverte a ordem: começa escolhendo o banco ou framework, e só depois tenta descobrir que dados de fato importam.
Ser orientado a dados é lembrar que, no final das contas, tudo que sobrevive em um sistema são os fatos registrados. Classes, serviços e até times mudam. Mas os dados ficam.
Exemplo guia: um pedido de e-commerce
Vamos pegar um caso que todo mundo conhece: comprar algo online.
Fluxo simplificado: Carrinho → Checkout → Pagamento → Faturamento → Entrega.
Agora olhe não para o código, mas para os dados que contam essa história:
- PedidoId identifica de forma única aquela compra.
- Itens guardam o que foi comprado.
- ValorTotal mostra quanto deve ser pago.
- StatusPagamento indica se o dinheiro entrou ou não.
- NotaFiscal registra a obrigação fiscal.
- CodigoRastreamento acompanha a entrega.
E os eventos que marcam a jornada:
- PedidoConfirmado
- PagamentoAprovado
- NotaFiscalEmitida
- PedidoDespachado
Esses eventos são como capítulos de um livro. Eles dizem o que aconteceu, em ordem, sem depender de classes ou métodos específicos. Se amanhã o time reescrever o módulo de checkout ou trocar de banco de dados, a narrativa do pedido continua de pé.
O que sobrevive à maré de frameworks, refatorações e reestruturações não é o código, mas os dados e eventos que contam a história de negócio.
Princípios que ajudam (dos clássicos)
Os livros que moldaram o jeito moderno de pensar software não falavam de hype, mas de fundamentos. E quando juntamos DDD, Clean Architecture, Fowler e até o GoF, todos apontam na mesma direção: proteger o significado dos dados e separar o essencial do acidental.
Do DDD (Eric Evans; Millett & Tune)
Linguagem Ubíqua: nomeie os dados como o negócio fala. PedidoConfirmado comunica mais do que OrderOK.
Bounded Context: cada time cuida de sua versão do mundo. O “cliente” do time de logística não precisa ter os mesmos atributos do “cliente” de marketing.
Agregados: defina o que precisa ficar consistente junto. Itens e valor total de um pedido são inseparáveis; a emissão da nota pode esperar.
Da Clean Architecture (Robert C. Martin)
Regras de negócio no centro: frameworks e bancos orbitam como detalhes periféricos.
Casos de uso: encapsulam entradas e saídas, mantendo os dados de aplicação independentes de tecnologia.
De Fowler (Patterns of Enterprise Application Architecture)
Service Layer: separa regras de negócio da interface de usuário e da infraestrutura.
Mapeamentos O/R: cuide para que o ORM não dite o formato dos seus dados de domínio.
Do GoF, Código Limpo e Refatoração
Adapter ajuda a traduzir contratos de dados entre contextos.
Observer encaixa como luva para reagir a eventos de domínio.
Value Objects dão semântica a dados crus (CPF, Email, Money).
Refatorar cheiros como Primitive Obsession e Data Clumps é, no fundo, dar dignidade aos dados.
No fim, todos esses princípios contam a mesma história: dados claros, significativos e protegidos são o que realmente mantém um sistema de pé.