Domain-Driven Design (DDD)

Domain-Driven Design (DDD) é um conjunto de boas práticas e vocabulário que vistam tornar mais simples a modelagem de sistemas complexos. Foi criada por Eric Evans em 2004 e tornada pública no seu famoso livro Domain-Driven Design, Tackling Complexity in the Heart of Software.

O principal objetivo de Eric Evans foi mostrar que em aplicações complexas o maior desafio do desenvolvedor é conseguir criar um modelo computacional que reflita diretamente a visão dos especialistas e não as questões tecnológicas inerentes a implementação computacional do modelo. Desenvolvedores e especialistas devem ser capazes de se comunicar usando uma mesma linguagem.

Conceitos

A abordagem DDD está fundamentada em alguns conceitos básicos.

Arquitetura em Camadas

Os objetos que modelam o domínio de conhecimento (regras de negócio) da aplicação não devem conter nada relacionado à sua representação em termos de interface com o usuário, persistência (bases de dados) ou funcionamento da aplicação. Em resumo, regras de negócio não podem estar espalhadas ao longo das camadas da aplicação.

Entidades

Entidades são objetos que possuem uma identidade própria e possuem um ciclo de vida bem definido.

Tipicamente haverá um único atributo cujo valor define a identidade do objeto. Assim, dois objetos são considerados iguais se tiverem a mesma identidade, independentemente dos valores dos outros atributos.

Entidades são criadas, alteradas e talvez destruídas por razões diretamente relacionadas às regras de negócio da aplicação.

Objetos Valor

Objetos valor (value objects) são objetos que não possuem identidade. Eles apenas reunem um conjunto de informações relacionadas.

Dois objetos valor são iguais se possuirem exatamente os mesmos valores para todos os seus atributos.

O exemplo clássico de objeto valor é a classe Endereço (formada por seus vários atributos, como, logradouro, número, complemento, CEP, cidade). Dois endereços são iguais apenas quando possuirem os mesmos valores.

Eventos do Domínio

Um evento é o registro de algo que aconteceu durante a vida da aplicação.

Um objeto do tipo entidade armazena o estado atual de um objeto mas não explica a trajetória de acontecimentos que levaram a este estado.

Objetos do tipo evento são imutáveis pois sempre representam algo que aconteceu.

Serviços

Na modelagem do domínio da apliacação nem todo conhecimento pode ser naturalmente considerado um objeto. Alguns processos ou transformações não são naturalmente associados a nenhum objeto em particular.

Por exemplo, em uma aplicação bancária, o procedimento para transferir dinheiro de uma conta para outra existe de forma independente. Ele não deveria ser associado a uma classe Conta ou ser associado a uma classe artificial.

Agregados

Um agregado é formado por objetos do tipo entidade e objetos valor que são fortemente relacionados. Seu objetivo é garantir a consistência das informações contidas em todos os objetos definindo uma única interface de acesso aos diversos objetos.

Repositórios

Repositórios são serviços que permitem ler ou armazenar agregados como se eles estivem todos em memória.

Um repositório contém o código necessário para acessar as bases de dados onde os agregados são armazenados.

Fábricas

A criação de agregados pode envolver a instanciação de diversos objetos (entidades e objetos valor) de modo a garantir a consistência dos dados.

Fábricas definem uma interface padronizada para a criação de agregados ou de outros objetos valor complexos.