CRUD Tradicional vs Abordagem DDD - II

Neste artigo vou continuar uma comparação com a implementação de um CRUD tradicional e a abordagem do Domain Driven Design.

Continuando o artigo anterior, antes de mostrar a modelagem usando a abordagem do DDD, vou apresentar os conceitos básicos relacionados com o DDD .

O que é Domain-Driven Design (DDD) ?

O Domain-Driven Design é uma abordagem de design de software que:

- Coloca o domínio do negócio no centro
- Usa o código para expressar regras reais
- Evita que o modelo seja guiado pelo banco ou framework

Fazendo a conexão com o módulo anterior:  “No CRUD, o banco manda. No DDD, o negócio manda.”

O Design Estratégico vs Design Tático

O DDD é dividido em duas grandes frentes que trabalham juntas para resolver a complexidade do software:

Design Estratégico é o "olhar de cima". Ele foca no negócio, definindo onde ficam as fronteiras de cada parte do sistema (Bounded Contexts) e como as diferentes equipes ou módulos se comunicam. O objetivo aqui é garantir que o software respeite a estrutura da empresa e que cada termo (Linguagem Ubíqua) tenha um significado único dentro do seu conte

Principais conceitos:

Bounded Context
Linguagem Ubíqua
Context Map

1. Bounded Context (Contexto Delimitado)

O domínio de um sistema grande é complexo demais para um modelo único. O Bounded Context é a fronteira que delimita onde um modelo específico se aplica. Em um sistema de vendas, o conceito de "Produto" para o setor de Catálogo (foco em marketing e descrição) é diferente do "Produto" para o Estoque (foco em dimensões e peso). Tentar criar uma classe única para ambos gera um código confuso e cheio de propriedades nulas.

2. Linguagem Ubíqua (Linguagem Onipresente)

É o vocabulário compartilhado entre desenvolvedores e especialistas de negócio (stakeholders). Se o dono da empresa chama o cancelamento de "Estorno", o código não deve usar DeleteOrder(), mas sim EstornarPedido(). Essa linguagem elimina a tradução mental, reduzindo erros de comunicação e garantindo que o código expresse exatamente o que o negócio faz.

3. Context Map (Mapa de Contextos)

Se os Bounded Contexts são as "nações" do seu sistema, o Context Map é o mapa diplomático que mostra como elas se relacionam. Ele define, por exemplo, se o contexto de Pagamentos depende do contexto de Pedidos (relação Cliente-Fornecedor) ou se eles apenas compartilham dados de forma neutra. É essencial para entender o impacto de uma mudança em uma parte do sistema sobre as outras.

“O Design Estratégico define onde cada modelo vale.”

O Design Tático é o "mão na massa". Ele foca no código e em como modelar o interior de cada contexto definido na estratégia. É aqui que entram os padrões que estamos discutindo no curso: Agregados, Entidades Ricas, Value Objects, Repositórios e Serviços de Domínio. É o conjunto de ferramentas técnicas para garantir que as regras de negócio sejam protegidas e o código seja sustentável.

Principais conceitos:

Entidade
Value Object
Aggregate
Aggregate Root
Invariantes

1- Entidade: É um objeto definido por sua identidade única e contínua, e não apenas por seus atributos. Mesmo que seus dados mudem (como o nome de um Cliente), ele permanece o mesmo objeto ao longo do tempo, geralmente identificado por um ID persistente. Exemplos: Pedido, Cliente, Produto, etc.

2- Value Object: É um objeto definido exclusivamente pelo conjunto de seus valores, sem identidade própria. Se você alterar qualquer atributo de um Endereço ou de uma Cor, você terá um novo objeto; por serem imutáveis, eles garantem segurança e clareza ao modelo. Exemplos: Endereco, Dinheiro, etc.

3- Aggregate: É um cluster de objetos (Entidades e Value Objects) que são tratados como uma única unidade de consistência para o negócio. Ele define uma fronteira clara, garantindo que todas as mudanças em seus componentes internos respeitem as regras do grupo. No sistema o Aggregate Pedido inclui Pedido, ItemPedido e Pagamento.

4- Aggregate Root: É a única entidade de entrada de um Agregado; nada de fora pode acessar os objetos internos sem passar por ela. Ela é responsável por manter a integridade de todo o grupo e garantir que as operações de negócio sejam executadas corretamente. Pedido é um Aggregate Root , assim ItemPedideo não pode ser sa sozinho e Pagameto não pode existir sem Pedido.

5- Invariantes: São as regras de negócio que devem ser preservadas e permanecer verdadeiras o tempo todo durante uma operação. O Agregado utiliza essas regras para impedir estados inválidos, como um pedido com valor negativo ou um item sem produto. Exemplos:  Pedido pago não pode ser alterado, Item não pode ter quantidade negativa, Total do Pedido deve bater com os itens, etc.

O Design Tático define como o modelo vive no código.

Ligação direta com o CRUD tradicional

A transição para uma mentalidade de domínio exige a compreensão fundamental de que Domínio não é Persistência. No desenvolvimento orientado a objetos, as regras de negócio devem ser modeladas de forma independente das restrições técnicas, permitindo que o foco total esteja na lógica do sistema antes de decidir como os dados serão salvos.

Ao separar essas preocupações, garantimos que o banco de dados seja apenas um detalhe de implementação, adaptando o ORM às necessidades do negócio e não o contrário.

Nesse contexto, é crucial entender que Entidade não é Tabela. Enquanto uma tabela no banco de dados é uma estrutura estática de armazenamento, uma Entidade no DDD é uma unidade rica em comportamento, onde os métodos expressam as intenções do negócio e protegem seu estado.

Complementando essa estrutura, os Value Objects trazem clareza e segurança ao modelo, promovendoa imutabilidade; ao invés de tratar dados complexos como simples strings ou números, criamos objetos que representam conceitos reais e que não podem ser corrompidos.

Por fim, o modelo de domínio torna-se o guardião das Invariantes, as regras essenciais que devem ser verdadeiras o tempo todo. Em vez de espalhar validações e cálculos por controladores ou serviços externos, essas regras são protegidas dentro das próprias entidades e agregados.

Isso garante que o sistema nunca entre em um estado inválido, centralizando a inteligência e facilitando a manutenção, já que qualquer mudança na regra de negócio acontece em um único lugar seguro.

Agora vamos ver como isso muda quando o domínio passa a se defender. !!!

E estamos conversados...  

"Assim que, se alguém está em Cristo, nova criatura é; as coisas velhas já passaram; eis que tudo se fez novo."
2 Coríntios 5:17