none
Duvidas em relação ao DDD. RRS feed

  • Pergunta

  • Ola Pessoal, alguem poderia me dar uma ajuda?

    Estou tentando iniciar uma aplicação implantando o conceito de Domain Driven Design mas estou com algumas duvidas.

    As classes de entidades deverão ser POCOS (apenas geters e setters e um construtor padrão??)

    As classes de serviços alem de centralizar as regras do negócio deverão ser responsaveis por chamar as interfaces dos repositórios, tipo chamar um método salvar cliente?


    Posso implementar o DDD em um modelo MVC??

    Agradeço desde já.
    segunda-feira, 22 de fevereiro de 2010 18:14

Respostas

  • Ola, Beto.

    Nao deixe realmente de postar nao. O assunto é muito interessante, vasto e deve ser discutido sempre que possivel para ter evolucao de todo mundo que participar.

    Nao deixe de marcar as respostas se elas forem uteis, ok?!

    Sobre O repositorio dentro da entidade, esse é um item que cai em contradicao entre alguns partidarios de DDD. Eu acho perfeitamente normal e aceitavel, afinal, o repositorio faz parte do dominio. A abstracao dele, claro. Isso pode ser feito como vc fez via factory ou por um container de injecao de dependencia, seja o que for.
    So acho que o seu exemplo nao foi bom, pq ele esta, na classe carga, salvando a entidade.
    Isso nao faz sentido. O responsavel por guardar o objeto é o seu repositorio, uma entidade nao sabe se salvar. Ao saber se salvar, mudamos o padrao:
    deixamos de usar o Repository Pattern (http://martinfowler.com/eaaCatalog/repository.html) para usar o active record pattern (http://martinfowler.com/eaaCatalog/activeRecord.html)

    Um uso de repositorio dentro da entidade seria quando ela, pra definir alguma logica ou informacao, deva consultar outros itens existentes no contexto. Isso acontece bastante com entidade que participam de workflow.

    Abs
    Gustavo Rocha, MCTS, MCPD, CSM, Arquiteto de Software - http://subindoaladeira.wordpress.com/
    quarta-feira, 24 de fevereiro de 2010 15:32
  • Ola, Beto.

    Nao deixe realmente de postar nao. O assunto é muito interessante, vasto e deve ser discutido sempre que possivel para ter evolucao de todo mundo que participar.

    Nao deixe de marcar as respostas se elas forem uteis, ok?!

    Sobre O repositorio dentro da entidade, esse é um item que cai em contradicao entre alguns partidarios de DDD. Eu acho perfeitamente normal e aceitavel, afinal, o repositorio faz parte do dominio. A abstracao dele, claro. Isso pode ser feito como vc fez via factory ou por um container de injecao de dependencia, seja o que for.
    So acho que o seu exemplo nao foi bom, pq ele esta, na classe carga, salvando a entidade.
    Isso nao faz sentido. O responsavel por guardar o objeto é o seu repositorio, uma entidade nao sabe se salvar. Ao saber se salvar, mudamos o padrao:
    deixamos de usar o Repository Pattern (http://martinfowler.com/eaaCatalog/repository.html) para usar o active record pattern (http://martinfowler.com/eaaCatalog/activeRecord.html)

    Um uso de repositorio dentro da entidade seria quando ela, pra definir alguma logica ou informacao, deva consultar outros itens existentes no contexto. Isso acontece bastante com entidade que participam de workflow.

    Abs
    Gustavo Rocha, MCTS, MCPD, CSM, Arquiteto de Software - http://subindoaladeira.wordpress.com/


    Gustavo eu estou em um impasse e gostaria de dividir esta angústia com alguém :)...

    Imagine que eu tenho uma classe Banco e nela uma propriedade chama ClientesAtivos...sou partidário da sua visão sobre os repositórios (se eles são do domínio, porque não usá-los nas entidades)...porém para buscar os clientes ativos neste caso, eu teria que accesar o meu repositório de clientes e par isso teria que ter algo do tipo IoCHelper.Resolve<IClienteRepositorio>...isso não fere um pouco regra do DDD no que tange a separação de conceitos (negócio e infra)?

     


    Paulo Silva
    terça-feira, 26 de outubro de 2010 14:06

Todas as Respostas

  • Nao é isso, Beto.

    Vamos por partes:

    As classes nao devem ter apenas getters e setters, pelo contrario, e esse conceito nao é o que define poco.
    As classes devem sim como por definicao de objetos, ter estado e comportamento. Ou seja, os seus atributos e métodos;

    Respondendo a segunda e ampliando a primeira, servicos nao sao responsaveis por negócio. Quem cuida do negócio é o "dominio".
    Os servicos na abstracao fazem parte do dominio, mas o negocio e responsabilidade das entidades do dominio.
    O servico faz coisas inerentes a infra ou se utilizam dos objetos de dominio com suas respectivas logicas de negocio.
    Nao sao somente os servicos que chamam as interfaces de repositorio. Qualquer um pode chamar essa interface, pq o dominio é comum a todos.

    Pode sim e é bastante natural ddd com mvc.

    O assunto é vasto mas extremamente interessante, nao se incomode em perguntar.
    Abs
    Gustavo Rocha, MCTS, MCPD, CSM, Arquiteto de Software - http://subindoaladeira.wordpress.com/
    • Sugerido como Resposta Danimar Ribeiro terça-feira, 23 de fevereiro de 2010 11:32
    segunda-feira, 22 de fevereiro de 2010 23:34
  • Ola Gustavo,

     Agora ficou mais claro, ou seja como você disse: As  classes devem sim como por definicao de objetos, ter estado e comportamento. Ou seja, os seus atributos e métodos;

    E Realmente o assunto é bem vasto e interessante. (O que aumenta o meu interesse em aprender).

    Bom de qualquer forma, eu encomendei o livro Domain Driven Design de Eric Evans e vou me dedicar a aprender este conceito aplicando-o ao poucos em meus projetos de exemplos.

    Com certeza postarei mais duvidas aqui neste precioso forum e ao mesmo tempo ajudarei a esclarecer
    a medida que eu for avançando no assunto.

    Seria ótimo discutirmos o assunto, pois sei que este conceito veio para ficar.

    Obrigado pela resposta, pois agora sim as ideias estão começando a fazer sentido.

    quarta-feira, 24 de fevereiro de 2010 13:29
  • Agora outra pergunta Gustavo.

    Posso delegar a chamada do repositório para a propria classe de entidade internamente ?

    Exemplo:

    // classe entidade Carga

    // namespace
    class Carga
    {
       // construtor
       // getters e setters


         public void SalvarCarga()
        {
             
             IrepositorioCarga rep = FactoryRepositorioCarga.GetRepositorioSqlserver(); // poderia ser xml,mysql etc
             rep.SalvarCarga(this);
        }


    }




    quarta-feira, 24 de fevereiro de 2010 14:01
  • Ola, Beto.

    Nao deixe realmente de postar nao. O assunto é muito interessante, vasto e deve ser discutido sempre que possivel para ter evolucao de todo mundo que participar.

    Nao deixe de marcar as respostas se elas forem uteis, ok?!

    Sobre O repositorio dentro da entidade, esse é um item que cai em contradicao entre alguns partidarios de DDD. Eu acho perfeitamente normal e aceitavel, afinal, o repositorio faz parte do dominio. A abstracao dele, claro. Isso pode ser feito como vc fez via factory ou por um container de injecao de dependencia, seja o que for.
    So acho que o seu exemplo nao foi bom, pq ele esta, na classe carga, salvando a entidade.
    Isso nao faz sentido. O responsavel por guardar o objeto é o seu repositorio, uma entidade nao sabe se salvar. Ao saber se salvar, mudamos o padrao:
    deixamos de usar o Repository Pattern (http://martinfowler.com/eaaCatalog/repository.html) para usar o active record pattern (http://martinfowler.com/eaaCatalog/activeRecord.html)

    Um uso de repositorio dentro da entidade seria quando ela, pra definir alguma logica ou informacao, deva consultar outros itens existentes no contexto. Isso acontece bastante com entidade que participam de workflow.

    Abs
    Gustavo Rocha, MCTS, MCPD, CSM, Arquiteto de Software - http://subindoaladeira.wordpress.com/
    quarta-feira, 24 de fevereiro de 2010 15:32
  • Ola, Beto.

    Nao deixe realmente de postar nao. O assunto é muito interessante, vasto e deve ser discutido sempre que possivel para ter evolucao de todo mundo que participar.

    Nao deixe de marcar as respostas se elas forem uteis, ok?!

    Sobre O repositorio dentro da entidade, esse é um item que cai em contradicao entre alguns partidarios de DDD. Eu acho perfeitamente normal e aceitavel, afinal, o repositorio faz parte do dominio. A abstracao dele, claro. Isso pode ser feito como vc fez via factory ou por um container de injecao de dependencia, seja o que for.
    So acho que o seu exemplo nao foi bom, pq ele esta, na classe carga, salvando a entidade.
    Isso nao faz sentido. O responsavel por guardar o objeto é o seu repositorio, uma entidade nao sabe se salvar. Ao saber se salvar, mudamos o padrao:
    deixamos de usar o Repository Pattern (http://martinfowler.com/eaaCatalog/repository.html) para usar o active record pattern (http://martinfowler.com/eaaCatalog/activeRecord.html)

    Um uso de repositorio dentro da entidade seria quando ela, pra definir alguma logica ou informacao, deva consultar outros itens existentes no contexto. Isso acontece bastante com entidade que participam de workflow.

    Abs
    Gustavo Rocha, MCTS, MCPD, CSM, Arquiteto de Software - http://subindoaladeira.wordpress.com/


    Gustavo eu estou em um impasse e gostaria de dividir esta angústia com alguém :)...

    Imagine que eu tenho uma classe Banco e nela uma propriedade chama ClientesAtivos...sou partidário da sua visão sobre os repositórios (se eles são do domínio, porque não usá-los nas entidades)...porém para buscar os clientes ativos neste caso, eu teria que accesar o meu repositório de clientes e par isso teria que ter algo do tipo IoCHelper.Resolve<IClienteRepositorio>...isso não fere um pouco regra do DDD no que tange a separação de conceitos (negócio e infra)?

     


    Paulo Silva
    terça-feira, 26 de outubro de 2010 14:06
  • Paulo, nao sei se ainda esta em tempo.

    O repositorio tambem faz parte do domínio logo eh natural que uma classe consulte um repositorio.

    O problema de infra no container de DI realmente nao deve ser passado ao dominio. A solucao pra isso é inversao de controle.

    Ao criar a classe banco, passe uma instancia de IClienteRepositorio pra ela. Assim vc consegue o acesso sem poluir o dominio.

    Dependendo tbm do ORM que vc estiver utilizando ou a fabrica do objeto, ele mesmo pode fazer a resolucao do IReposioty sem conhecero o container.

     

    Abs

    Gustavo Rocha


    Gustavo Rocha, MCTS, MCPD, CSM, Arquiteto de Software - http://subindoaladeira.wordpress.com/
    quinta-feira, 31 de março de 2011 20:55
  • DDD sugere que o domínio se valide e se salve sozinho?
    Como Active Rercord??

    Me parece estranho isso
    quarta-feira, 21 de janeiro de 2015 19:36