Usuário com melhor resposta
Domain-Driven Design ou DDD

Pergunta
-
Olá galera,
Estou começando a estudar DDD, e já li vários artigos sobre o assunto, agora irei comprar o livro do Eric Evans (Domain-Driven Design) para ter uma abragência maior do que é o DDD.
Mas antes tenho algumas dúvidas, são elas:
1 - Como identificar o meu Domínio?
2 - O Domínio é o sistema em seu todo?
3 - Porque a aplicação está fora do Domínio? (Se é que está mesmo!)
4 - O que é exatamente a infra-estrutura?
5 - Porque usar a interface se o repositório faz parte do Domínio?
6 - Qual a diferença em Repositório e DAL e/ou DAO?
Obrigado por momento!
Alan
Alan Santana
Respostas
-
Boa tarde Alan.
Acho que você está com uma definição errada de domínio. Na abordagem do DDD, domínio é refente às regras de negócio. Ou seja, o domínio trata das questões de funcionalidade do sistema. Por exemplo, o domínio de um sistema de ERP é todas as regras de negócio, legislação fiscal, etc, que devem ser contempladas pelo sistema. Você consegue identificar seu domínio quando olha para o sistema a partir do prisma do cliente, o qual possui uma visão focada apenas no valor de negócio que o sistema irá gerar.
O domínio não é o sistema todo, ele é apenas a parte de negócio, como alguns gostam de definir, BLL (Business Logic Layer - Camada de Lógica/Regra de negócio). Questões referentes à infra-estrutura, como relacionamentos com a base de dados ou lógica de interface não fazem parte do domínio.
Não entendi muito bem o que você quis dizer com uma aplicação fora do domínio, mas acredito que você se refere a aplicações que fogem do escopo do sistema ou implementações internas que não satisfazem diretamente uma regra de negócio. Na filosofia do DDD, você deve implementar apenas aquilo que é necessário ao domínio, mesmo que às vezes tenha que deixar de lado práticas comuns de orientação a objeto por exemplo. Esta filosofia prega que deve ser implementado apenas aquilo que é necessário para atender uma necessidade do domínio, nada mais do que isso. Qualquer implementação que fuja desta regra está fora do domínio.
Infra-estrutura é toda a parte de relacionamento com o banco de dados por exemplo. A conexão com a base não faz parte do escopo do domínio, é uma implementação específica que varia de banco para banco, e a camada do domínio não tem que se preocupar com isso.
Em relação às suas duas ultimas perguntas, utiliza-se o padrão de repositório justamente para abstrair a implementação da infra-estrutura. Vamos olhar um caso prático. Você esta desenvolvendo um sistema com um conjunto de regras de negócio que deve armazenar um conjunto de informações na base de dados. Ao utilizar o padrão de repositório, sua camada de negócio não tem conhecimento sobre qual banco está sendo utilizado ou como os dados são armazenados. Se você usa NHibernate ou Entity Framework é invisível para sua camada de negócio. Dessa forma, se em sua implementação inicial você utiliza uma base oracle e posteriormente necessite migra para SQL Server, você não terá que refazer nenhuma implementação na camada de negócio, basta apenas refazer sua camada de infra-estrutura que se relaciona com a Base. Se você utiliza DAL/DAO, fica preso à infra-estrutura, ou seja, a qual banco de dados está utilizando. O que claro, não é uma boa coisa. DAL/DAO é uma implementação específica, que varia de acordo com o tipo de banco de dados, Repositório é uma interface genérica, que espõe apenas os operações e pode ser implementada para qualquer base de dados, e é acessada pelo dompinio do sistema.
Espero que tenha esclarecido sua dúvida, qualquer dúvida estou à disposição.
- Marcado como Resposta Alan Santana segunda-feira, 31 de janeiro de 2011 19:15
-
Vamos supor que a interface IRepository é a interface por fornecer uma abstração para operações de dados. Ela irá possuir as operações básicas, inserir, alterar, buscar e excluir. Esssa interface fará parte do domínio, assim as classes de domínio não terão conhecimento algum sobre a implementação de infra. Na sua camada de infra, você terá classes que implementam a inteface IRepository, e realizarão as operações na base de dados. Dessa forma, a implementação de infra fica apenas na parte de infra. Como eu falei assima, caso haja a necessidade de uma mudança de banco de dados, não haverá impacto sobre seu domínio. Dê uma olhada nesses links, eles explicam melhor o pattern Repository:
http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/10/08/the-repository-pattern.aspx
http://msdn.microsoft.com/en-us/library/ff649690.aspx
Espero que ajude.
- Marcado como Resposta Alan Santana segunda-feira, 31 de janeiro de 2011 19:15
Todas as Respostas
-
Boa tarde Alan.
Acho que você está com uma definição errada de domínio. Na abordagem do DDD, domínio é refente às regras de negócio. Ou seja, o domínio trata das questões de funcionalidade do sistema. Por exemplo, o domínio de um sistema de ERP é todas as regras de negócio, legislação fiscal, etc, que devem ser contempladas pelo sistema. Você consegue identificar seu domínio quando olha para o sistema a partir do prisma do cliente, o qual possui uma visão focada apenas no valor de negócio que o sistema irá gerar.
O domínio não é o sistema todo, ele é apenas a parte de negócio, como alguns gostam de definir, BLL (Business Logic Layer - Camada de Lógica/Regra de negócio). Questões referentes à infra-estrutura, como relacionamentos com a base de dados ou lógica de interface não fazem parte do domínio.
Não entendi muito bem o que você quis dizer com uma aplicação fora do domínio, mas acredito que você se refere a aplicações que fogem do escopo do sistema ou implementações internas que não satisfazem diretamente uma regra de negócio. Na filosofia do DDD, você deve implementar apenas aquilo que é necessário ao domínio, mesmo que às vezes tenha que deixar de lado práticas comuns de orientação a objeto por exemplo. Esta filosofia prega que deve ser implementado apenas aquilo que é necessário para atender uma necessidade do domínio, nada mais do que isso. Qualquer implementação que fuja desta regra está fora do domínio.
Infra-estrutura é toda a parte de relacionamento com o banco de dados por exemplo. A conexão com a base não faz parte do escopo do domínio, é uma implementação específica que varia de banco para banco, e a camada do domínio não tem que se preocupar com isso.
Em relação às suas duas ultimas perguntas, utiliza-se o padrão de repositório justamente para abstrair a implementação da infra-estrutura. Vamos olhar um caso prático. Você esta desenvolvendo um sistema com um conjunto de regras de negócio que deve armazenar um conjunto de informações na base de dados. Ao utilizar o padrão de repositório, sua camada de negócio não tem conhecimento sobre qual banco está sendo utilizado ou como os dados são armazenados. Se você usa NHibernate ou Entity Framework é invisível para sua camada de negócio. Dessa forma, se em sua implementação inicial você utiliza uma base oracle e posteriormente necessite migra para SQL Server, você não terá que refazer nenhuma implementação na camada de negócio, basta apenas refazer sua camada de infra-estrutura que se relaciona com a Base. Se você utiliza DAL/DAO, fica preso à infra-estrutura, ou seja, a qual banco de dados está utilizando. O que claro, não é uma boa coisa. DAL/DAO é uma implementação específica, que varia de acordo com o tipo de banco de dados, Repositório é uma interface genérica, que espõe apenas os operações e pode ser implementada para qualquer base de dados, e é acessada pelo dompinio do sistema.
Espero que tenha esclarecido sua dúvida, qualquer dúvida estou à disposição.
- Marcado como Resposta Alan Santana segunda-feira, 31 de janeiro de 2011 19:15
-
Olá Leandro, Então, deixa ver se entendi a coisa!
A estrutura padrão do DDD é: Interface com o usuário, Aplicação, Domínio e infra-estrutura, certo?
A camada interface: css, imagens, formulário, arquivos e etc...
A camada Aplicação: Objetos, Interfaces e ...
A camada Domínio: Toda regra de negócio do sistema(Como uma BLL).
A camada Infra-Estrutura: Acesso a Banco.
Neste caso, é incorreto afirmar que reposiório faz parte do Domínio, sendo que por sua vez o seu acesso é feito por interface que está na camada de aplicação. Sendo assim posso dizer que o Domínio conhece a aplicação.
E no caso de serviço WS, ele fica na Camada de Aplicação? Acredito que sim!
Será que estou errado ou misturando as coisas.
Obrigado!
Alan Santana -
Vamos supor que a interface IRepository é a interface por fornecer uma abstração para operações de dados. Ela irá possuir as operações básicas, inserir, alterar, buscar e excluir. Esssa interface fará parte do domínio, assim as classes de domínio não terão conhecimento algum sobre a implementação de infra. Na sua camada de infra, você terá classes que implementam a inteface IRepository, e realizarão as operações na base de dados. Dessa forma, a implementação de infra fica apenas na parte de infra. Como eu falei assima, caso haja a necessidade de uma mudança de banco de dados, não haverá impacto sobre seu domínio. Dê uma olhada nesses links, eles explicam melhor o pattern Repository:
http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/10/08/the-repository-pattern.aspx
http://msdn.microsoft.com/en-us/library/ff649690.aspx
Espero que ajude.
- Marcado como Resposta Alan Santana segunda-feira, 31 de janeiro de 2011 19:15
-
Leandro,
Dei outra lida em outros artigos e a sua resposta me fez enxergar legal o conceito. Ainda não li os sites que você passou, mas vou entrar hoje a noita para ler.
Eu tava misturando algumas coisas, mas agora sei cada papel de cada camada, só vai faltar agora a prática do dia-a-dia para saber como utilizar o conceito da melhor forma.
Vou fazer alguns teste ainda hoje e vou te mandar como estou fazendo.
Obrigado!
Alan Santana -