MDD - O coração do Domain Driven Design

Domain Driven Design(Projeto Orientado a Domínio), conceito que surgiu do título do livro de Eric Evans, vem sendo abordado com frequência pela Engenharia de Software como um conjunto de padrões que trazem muito sucesso aos projetos. O DDD é visto como o ápice da Orientação à Objetos na projetização do software, pois, nele, contém príncipios que trazem a essência da OO, e que vão muito além de heranças e polimorfismo, como: Alinhamento do código com o negócio, favorecer reutilização, mínimo de acoplamento e independência da tecnologia. Para isso, o DDD segue a filosofia de contato dos desenvolvedores com os especialistas de domínio, com um modelo bem feito, organizado e que não foque em tecnologia e sim em entender as regras de negócio e como elas devem estar refletidas no código. Porém, para ter êxito nesses itens, é necessário compreensão da importância do MDD para o sucesso do projeto.

O Model Driven Design(Projeto Dirigido Pelo Modelo), que na minha opinião é o coração do Domain Driven Design, nos ajuda a projetar um software que atende perfeitamente o domínio. Para isso, é necessário, em primeiro lugar, que se estabeleça uma Linguagem Ubíqua, ou seja, uma 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. Esse passo, tem como objetivo, fazer com que as conversas diárias sobre o negócio, utilizem os mesmos termos que são definidos no sistema. Por exemplo, a seguinte frase: “Temos que emitir a fatura para o cliente antes da data limite”, vamos ter no 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.

Para isso, devemos perceber a distância que há em um time que cria software; temos de um lado os especialistas de negócio e de outro os desenvolvedores e arquitetos. Para o MDD, em um processo ágil, a criação do modelo deve ser feita em grupo, com todas as pessoas juntas. Caso seja feita por profissionais de apenas um dos lados, o projeto corre o risco de ter um modelo que não é implementável, ou que usará uma tecnologia inadequada, e principalmente, se os programadores codificarem sem se basear num modelo consistente, provavelmente desenvolverão um software que simplesmente não serve para o domínio.

Com essa aproximação dos analistas de negócio, teremos um time de desenvolvimento que entende a real necessidade do cliente, o que traz uma certeza de uma diminuição do esforço demandado no projeto, pois além de entender a necessidade real do cliente, os programadores se sentirão responsáveis pelo modelo e entenderão como o modelo funciona, e irão produzir um software que atenderá completamente o domínio.