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.
Top comments (0)