A idéia 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. Só aparece no modelo aquilo que está no
negócio.
Em um time que cria software temos de um lado os especialistas de
negócio e de outro os desenvolvedores e arquitetos. Num processo ágil
defendido pelo MDD a criação do modelo abstrato deve ser feita em grupo,
com todas as 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 Modelers). Se os programadores não se sentirem
responsáveis pelo modelo ou não entenderem como o modelo funciona, então
o modelo não terá relação alguma com o software produzido por essas
pessoas.
O processo de maturação de um sistema desenvolvido usando MDD deve ser
contínuo. O modelo servirá de guia para a criação do 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.
Uma vez que decidimos criar um modelo usando MDD, precisamos,
inicialmente, isolar o modelo de domínio das demais partes que compõem o
sistema. Estas partes são:
- Interface de Usuário – parte responsável pela exibição de informações do sistema ao usuário e também por interpretar comandos do usuário;
- Aplicação – essa camada não possui lógica de
negócio. Ela é apenas uma camada fina, responsável por conectar a
Interface de Usuário às camadas inferiores;
- Domínio – representa os conceitos, regras e lógicas
de negócio. Todo o foco de DDD está nessa camada.
- Infra-estrutura – fornece recursos técnicos que
darão suporte às camadas superiores. São normalmente as partes de um
sistema responsáveis por persistência de dados, conexões com bancos de
dados, envio de mensagens por redes, gravação e leitura de discos, etc.
Fonte: http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/
A arquitetura proposta pelo DDD é formada por:
1. Camada de Apresentação (User Interface): Responsável por interpretar os comandos do usuário;
2. Camada de Aplicação (Application): Não contém regras de negócio ou código referente ao domínio, apenas coordena tarefas e delega trabalhos;
3. Camada de Modelo (Domain): É o coração do sistema. Responsável por representar o domínio e suas regras de negócio;
4. Camada de Infraestrutura (Infrastructure): Provê recursos técnicos para o sistema, como persistência de dados.
fonte: http://www.devmedia.com.br/java-e-domain-driven-design-na-pratica-java-magazine-87/19019