Modelagem de Domínio: Uma Proposta

atolini — Sun, 31 May 2026 17:59:06 +0000

A proposta deste artigo é apresentar a forma como aplico Domain-Driven Design (DDD) em meus projetos e, principalmente, discutir algumas dificuldades recorrentes ao abordar Design de Software em equipes modernas de desenvolvimento.

Hoje, é comum encontrar times extremamente focados em aspectos operacionais, infraestrutura, observabilidade, escalabilidade e pipelines de entrega. Embora esses pontos sejam importantes, o design do software frequentemente acaba relegado a segundo plano, quase como um aspecto “estético” da aplicação, e não como um fator determinante para sua evolução, manutenção e aderência às regras de negócio.

Outro ponto que considero importante é a maneira como o DDD costuma ser interpretado. Muitas vezes, ele é reduzido à ideia de “isolar o domínio” em uma camada específica da aplicação. Esse entendimento, porém, é limitado. A proposta de Eric Evans vai muito além disso: construir software através de modelos ricos, compostos por objetos altamente expressivos e capazes de representar, com clareza, as regras e comportamentos do negócio.

O isolamento da camada de domínio é apenas uma consequência natural desse processo. Quando o domínio é bem modelado, torna-se possível desacoplá-lo de preocupações técnicas e de infraestrutura, preservando a linguagem do negócio e reduzindo o impacto de mudanças externas sobre as regras centrais do sistema.

Existe quase sempre mais de uma forma de modelar uma regra de negócio, os relacionamentos entre entidades e os fluxos da aplicação. E a maneira como essas decisões são tomadas pode determinar o sucesso ou o fracasso de um projeto em acompanhar a evolução das demandas do negócio.

Recentemente, me deparei com um cenário relativamente simples, mas que exemplifica bem esse problema.

Duas aplicações manipulavam o mesmo conceito de negócio:

A primeira era responsável por manter os registros de ativos problemáticos (dívidas).
A segunda era responsável pelos registros contábeis relacionados a esses ativos.

Quando um ativo passava a ser considerado “problemático”, um evento era enviado para a aplicação contábil, que então realizava dois novos lançamentos no livro contábil da empresa.

À primeira vista, a solução parecia adequada e atendia às regras de negócio. Contudo, um problema começou a surgir:

O que deveria acontecer quando um ativo deixasse de ser considerado problemático?

Esse tipo de questionamento é justamente onde o design do software começa a demonstrar sua importância. Dependendo de como o domínio foi modelado, a reversão desse estado pode exigir desde simples ajustes até uma cascata de compensações, inconsistências contábeis e acoplamentos difíceis de manter.

E é exatamente nesse ponto que o DDD deixa de ser apenas uma organização de camadas e passa a se tornar uma ferramenta estratégica para modelar comportamentos complexos do negócio.

DEV Community: atolini

Modelagem de Domínio: Uma Proposta