Domain Driven Design

Significa projeto Orientado a Domínio. Pode ser visto como a volta da orientação a objetos. Quando se fala em Orientação a Objetos, pensa-se logo em classes, heranças, polimorfismo, encapsulamento. Mas a essência da orientação a objetos também tem coisas como:

Alinhamento do código com o negócio

O contato dos desenvolvedores com os especialistas do domínio é algo essencial.

Favorecer a reutilização

Os blocos de construção, facilitam aproveitar um mesmo conceito de domínio ou um mesmo código em vários lugares.

Acoplamento mínimo

Com um modelo bem feito, organizado, as várias partes de um sistema interagem sem que haja muita dependência entre módulos ou classes de objetos de conceitos distintos.

Independência da tecnologia

Domain Driven Design não foca em tecnologia, mas em entender as regras de negócio e como elas devem estar refletidas no código e no modelo de domínio. Não que a tecnologia utilizada não seja importante, mas esta não é uma preocupação de DDD.

Modelo em funcionamento

Para ter um software que atenda perfeitamente a um determinado domínio, é necessário que se estabeleça, em primeiro lugar, uma Linguagem Ubíqua*. Nessa linguagem estão termos que fazem parte das conversas diárias entre especialistas de negócio e times de desenvolvimento. Isso significa que, se durante uma conversa com um cliente do sistema de cobrança, por exemplo, ele disser: "Temos que emitir a fatura para o cliente antes da data limite", vamos ter no nosso código alguma coisa do tipo:

• Uma classe para a entidade Cliente;
• Uma classe para a entidade Fatura;
• Algum serviço que tenha um método emitir;
• Algum atributo com o nome de data limite.

Utilizando a Longuagem Ubíqua, criamos um modelo de domínio através do Projeto Dirigido pelo Modelo (Model Driven Design - MDD). A ideia por trás de MDD é a de que o seu modelo abstrato deve ser uma representação perfeita do seu domínio. Tudo que existe no seu negócio deve aparecer no modelo.

Num processo ágil defendido pelo MDD, a criação do modelo abstrato deve ser feita em grupo, com todas pessoas juntas. Se arquitetos e analistas de negócio criarem o modelo sem a participação dos programadores, corre-se o risco de criar um modelo que não é implementável ou que usará uma tecnologia inadequada. Da mesma forma, se os programadores codificarem sem se basear num modelo consistente, provavelmente desenvolverão um software que simplesmente não serve para o domínio. Em DDD, parte das pessoas que modelam o domínio são necessariamente pessoas que colocam a mão em código (Hands-on Modellers).

O processo de maturação de um sistema utilizando MDD deve ser contínuo. O modelo servirá de guia para a criação de código e, ao mesmo tempo, o código ajuda a aperfeiçoar o modelo. O contato contínuo com o código trará insights aos programadores, que irão refatorar o código. Essa refatoração deverá ser feita não só no código, mas também no próprio modelo.

Blocos de construção do Model Driven Design

Decidindo pela criação de um modelo utilizando MDD, precisamos, inicialmente, isolar o modelo de domínio das demais partes que compõem o sistema. Essa separação pode ser feita utilizando-se uma arquitetura em camadas, que dividirá a aplicação em quatro partes

Interface do Usuário

Responsável pela exibição de informações do sistema ao usuário e também por interpretar comandos do usuário.

Aplicação

Não possui lógica de negócio. É responsável por conectar a Interface de Usuário às camadas inferiores.

Domínio

Representa conceitos, regras e lógicas de negócio. Todo o foco de DDD está nesta camada.

Infra-estrutura

Fornece recursos técnicos que darão suporte às camadas superiores.

Após dividir o sistema em camadas, preocupamo-nos apenas com a camada de domínio. Para modelar esta parte, utilizamos alguns padrões propostos em DDD. Esses padrões são chamados de blocos de construção e serão utilizados para representar o modelo abstrato. Estes blocos podem ser:

Entidades

Classes de objetos que necessitam de uma identidade. Normalmente são elementos do domínio que possuem ciclo de vida dentro de nossa aplicação: um Cliente, por exemplo, se cadastra no sistema, faz compras, se torna inativo, é excluído, etc.

Objetos de Valores

Objetos que só carregam valores, mas que não possuem distinção de identidade. Bons exemplos seriam strings, números ou cores.

Agregados

Compostos de entidades ou objetos de valores que são encapsulados numa única classe. Serve para manter a integridade do modelo. Elege-se uma classe para servir de raiz do Agregado. Quando algum cliente necessitar manipular dados de uma das classes que compõem o Agregado, essa manipulação só poderá ser feita através da raiz.

Fábricas

Classes responsáveis pelo processo de criação dos Agregados ou dos Objetos de Valores. Algumas vezes, agregados são relativamente complexos e não queremos manter a lógica de criação desses agregados nas classes que o compõem. Extraímos então as regras de criação para uma classe externa: a fábrica.

Serviços

Classes que cntém lógica de negócio, mas que não pertence a nenhuma Entidade ou Objetos de valores. Não guardam estado, ou seja, toda chamada a um mesmo serviço, dada uma mesma pré-condição, deve retornar sempre o mesmo resultado.

Repositórios

Classes responsáveis por administrar o ciclo de vida dos outros objetos, normalmente Entidades, Objetos de Valor e Agregados. Centralizam operações de criação, alteração e remoção de objetos. Em linguagens como java, são comumente implementados utilizando frameworks como o Hibernate.

Módulos

Abstrações que têm por objetivos agrupar classes por um determinado conceito de domínio. Em java, seriam os packages.



* Linguagem comum, com termos bem definidos, que fazem parte do domínio do negócio e que são usados por todas as pessoas que fazem parte do processo de desenvolvimento de software.

Fonte: http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/