Livro - Resumo sobre Domain-Driven Design de Eric Evans

 Você já ouviu falar sobre Domain-Driven Design ? (Projeto orientado a domínio)

Vou fazer uma pergunta : O que é mais importante em um software ?

- O código e a tecnologia usadas , diria o desenvolvedor;
- Os testes , diria o testador;
- O plano de projeto , diria o gerente;
- A arquitetura usada , diria o arquiteto;

Faltou alguma coisa ?

Sim, faltou !!!!

Faltou o cliente responder, que o mais importante, é o software resolver o problema dele.

Conclusão: O mais importante é a regra do negócio.

O Domain-Driven Desing (DDD) é uma abordagem de desenvolvimento de software que reúne um conjunto de conceitos, princípios e técnicas cujo foco esta no domínio e na lógica do domínio com o objetivo de criar um Domain Model ou (modelo do domínio).

Usar DDD significa desenvolver software de acordo com o domínio relacionado ao problema que estamos propondo resolver.

Obs: Nesse contexto domínio é o que o programa de software modela e o problema a que ele se propõe a resolver.(regras de negócio)

Conhecer o domínio é fundamental e criar um modelo e adotar uma arquitetura para aplicação que melhor reflitam os conceitos do domínio não é uma tarefa fácil nem uma tarefa somente para o analista.

O livro Domain Drive Design Quickly (que você vai poder baixar neste artigo) mostra um conjunto de idéias baseadas no livro de Eric Evans.

A figura abaixo mostra um mapa com esses conceitos que exibem o relacionamento entre os principais padrões DDD.(O exemplo da figura é o próprio DDD).

O DDD sugere uma arquitetura padrão de forma que possamos focar o domínio.

A seguir temos uma sugestão para arquitetura em camadas que pode ser usada no modelo do domínio : (Eu disse sugestão...)

  • User Interface - Apresenta a informação ao usuário e interpreta os seus comandos;
  • Application - Camada que coordena a atividade da aplicação. Não contém lógica de negócio;
  • Domain - Contém informação sobre o domínio; É o coração do negócio;
  • Infrastructure - Atua como uma library de suporte para as demais camadas; Realiza a comunicação entre as camadas; Implementa a persistência dos objetos de negócio;

Fonte: http://dddsample.sourceforge.net/architecture.html

O foco da abordagem é criar um domínio que “fale a língua” do usuário usando o que é conhecido como linguagem Ubíqua(ubiquitous language ou linguagem Comum,Onipresente)

Por linguagem Ubíqua (linguagem comum) entende-se que ao trabalhar com DDD devemos conversar usando uma mesma língua, em um único modelo, de forma que o mesmo seja compreendido pelo cliente, analista, projetista, desenhista, testador, gerente, etc. nesta linguagem, que seria a linguagem usada no dia a dia.

Quais as vantagens em usar DDD ?

O DDD não é a 'bala de prata' nem a panacéia universal, mas uma abordagem que deve ser considerada e aplicada ou não ao seu problema após você pensar e estudar muito sobre a suas aplicações e as suas conseqüências.

Lembre-se, você não tem que sair por ai aplicando (tentando aplicar) DDD a todos os tipos de projetos.

E por falar em estudar, um bom livro grátis para ler (em inglês) você encontra aqui:
  DomainDrivenDesignQuicklyOnline.zip

"Software design é uma arte e como qualquer arte ela não pode ser ensinada e aprendida como uma ciência precisa por meio de teoremas e fórmulas".(Floyd Marinescu)

"Tornou pois Jesus a dizer-lhes: Em verdade vos digo que eu sou a porta das ovelhas. Todos quantos vieram antes de mim são ladrões e salteadores; mas as ovelhas não os ouviram".
João 10:7-8

Referências:

José Carlos Macoratti