none
DDD Aggregates RRS feed

  • Discussão Geral

  • Ola pessoal faz um tempo que nao posto aqui, portanto surgiu tantas duvidas que preciso de explicacoes .

    Sobre DDD, tenho lido muito no consigo entender coisas basicas como como identificar o agregado, na verdade pra que serve realmente ?       

    Quanto nao usar , como identificar isso ?        

    tenho trabalhado em um sistema de ticket, chamados.

    Pra mim chamado e um root.

    chamado tem uma colecao de itens de chamados, e um cliente.

    na verdade eu nao consigo identificar esse tal de aggregates,   pra mim toda classe tem um id? minha classe chamado herda de 

     

    public class Chamado : Identidade

    nao sei se entenderam mais esta confuso mesmo  , se alguem puder explicar ?

     

    grato pessoal

    sexta-feira, 10 de dezembro de 2010 17:10

Todas as Respostas

  • Postei errado anteriormente,

    O agregado é a definição da relação de um determinado grupo de objetos que estão intimamente relacionados. Um dos principais objetivos do agregado é manter a lógica onde ela deve estar. No agregado temos três participantes, Root, Entidade, Value Object. Como exemplo: a nota fiscal e seus itens, a nota fiscal seria a raiz do agregado (uma entidade) e o item seria outra entidade. Um exemplo de value object neste caso poderia ser o endereço de entrega, olhar para o endereço de entrega ou para o item fora do contexto de sua nota fiscal poderia não ter nenhum significado. Algumas entidades e value objects não tem sentido em analisá-los isoladamente (sem a entidade que ele pertença), o que quero dizer, é que para um sistema X, olhar para esta entidade/value object isoladamente não traria nenhum valor.

    Manter a lógica onde ela deveria estar e identificar esses agregados simplifica e diminui a complexidade do sistema como um todo, na camada de acesso você teria interface apenas para buscar o root. Utilizaria o root para navegar para outras entidades. Há algumas restrições de navegação que devem ser consideradas dentro de um agregado que você pode verificar neste link: http://devlicio.us/blogs/casey/archive/2009/02/16/ddd-aggregates-and-aggregate-roots.aspx

    Este link é a referência da minha resposta. Achei bem esclarecedor, já havia lido o livro de Eric Evans, mas esses conceitos haviam ficado um pouco confuso também.


    Atenciosamente, Paulo R. Pereira de Souza
    http://paulosouza.net

    E-mail: paulorpereirasouza@hotmail.com.
    terça-feira, 22 de fevereiro de 2011 21:53
  • Só para te dar um exemplo de modelo, no caso da nota fiscal e endereço de entrega: supondo que a tabela nota fiscal tem os campos (rua, complemento, bairro, CEP e numero), nem por isso você gostaria que esses campos fossem propriedade na sua classe NotaFiscal. Você poderia criar uma classe Endereco que não teria Id, e que encapsularia essas propriedades (rua, complemento, bairro, CEP e numero), no cógido ficaria notaFiscal.EnderecoEntrega.Rua = "Alguma Rua", sua camada de acesso a dados que seria responsável por construir sua classe NotaFiscal dessa forma.

    Atenciosamente, Paulo R. Pereira de Souza
    http://paulosouza.net
    E-mail: paulorpereirasouza@hotmail.com. twitter facebook linkedin
    terça-feira, 22 de fevereiro de 2011 22:00
  • Olá Paulo, Embora o post tenha bastante tempo, tenho uma duvida sobre o que você mencionou... Estendendo o seu exemplo, imagine que eu tenha um cadastro de usuário, que seria outro agregado. Eu teria que criar uma nova classe de endereço para usuário, mesmo ele sendo um value object? Ou poderia utilizar a classe endereço existente, mesmo ela estando presente em outro agregado? Abraço Pablo lima pablolima@outlook.com
    sábado, 31 de maio de 2014 17:32