none
Domain-Driven Design ou DDD RRS feed

  • 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
    segunda-feira, 31 de janeiro de 2011 14:25

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
    segunda-feira, 31 de janeiro de 2011 15:42
  • 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://weblogs.asp.net/fredriknormen/archive/2008/04/24/what-purpose-does-the-repository-pattern-have.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
    segunda-feira, 31 de janeiro de 2011 18:52

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
    segunda-feira, 31 de janeiro de 2011 15:42
  • 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
    segunda-feira, 31 de janeiro de 2011 17:44
  • 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://weblogs.asp.net/fredriknormen/archive/2008/04/24/what-purpose-does-the-repository-pattern-have.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
    segunda-feira, 31 de janeiro de 2011 18:52
  • 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
    segunda-feira, 31 de janeiro de 2011 19:15
  • Beleza Alan, qualque dúvida to aí.

    Abraço.

    segunda-feira, 31 de janeiro de 2011 19:42