Diferenças entre Domain Driven Design e Model Drinven Design
Significa Projeto Orientado a Domínio e veio do livro escrito por Eric Evans. Como diz o Wikipedia é uma abordagem de desenvolvimento de software para as necessidades complexas, fechando a lacuna entre a realidade do negócio e o código.
A ideia principal do DDD é capturar o modelo para o código. Mantendo seu software voltado para o problema e não restrito à solução. Assim quando você procura algo importante sobre o domínio você saberá exatamente onde está.
Linguagem Ubíqua
É uma linguagem comum, com termos bem definidos, que fazem parte do processo de desenvolvimento. É importante para que todos falem a mesma língua, baseado na informação que puder conseguir do cliente. Como exemplo, se um cliente chama o dinheiro do caixa de numerário, sempre que nos referenciarmos ao dinheiro do caixa no software e nas reuniões, ele será numerário. Assim evita erros de interpretação.
É importante que todos os membros dentro do projeto estejam comprometidos com a linguagem Ubíqua, e tentar readequar sempre que for percebido que um termo tem mais de um significado.
Apenas desta forma poderemos ter o modelo abstrato como uma representação perfeita do domínio.
Model Driven Design (MDD)
A ideia por trás do MDD é a de que o seu modelo abstrato deve ser a representação perfeita do seu domínio. Seu processo de maturação deve ser contínuo. Este modelo servirá de guia para a criação do código e, ao mesmo tempo, o código ajuda a aperfeiçoar o modelo. Este contato contínuo trará aos programadores um insights para a refatoração.
Blocos de Construção do MDD
Precisamos isolar o modelo das demais partes. Essa separação sera feira utilizando-se de arquitetura em camadas:
- Interface de Usuário: É a parte de interação com o usuário e interpretação dos seus comandos;
- Aplicação: É uma camada sem lógica de negócio, responsável por conectar a interface as camadas inferiores
- Domínio: Responsável por toda a regra de negócio, Todo o foco do DDD esta aqui.
- Infra-estrutura: Responsável por fornecer os recursos para suporte as camadas superiores. São as partes de dados e persistência em geral.
Conclusão
Diante desta introdução ao DDD percebe-se que a ideia que gira em seu turno, e montar sua aplicação baseada no que o cliente deseja. Compreendendo exatamente as funções do sistema, abrangendo esta compreensão inclusive na linguagem utilizada pelo cliente. Fica evidente também que o MDD (Model Driven Design) é a parte maior, e uma das camadas (a camada de lógica) é que abrange o DDD (Domain Driven Design)
Referências
http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/
http://en.wikipedia.org/wiki/Domain-driven_design
http://www.agileandart.com/portfolio/mdd-model-driven-design/
http://msdn.microsoft.com/pt-br/magazine/dd419654.aspx
http://www.inf.ufsc.br/~ricardo/publications/Asoo97.pdf
