Olá
Eu tenho um Aggregate chamado TabelaPreco, e dele eu possuo uma lista de PrecoProdutoVO. Acontece que existem tabelas de preço com 3 mil produtos, e isso tem consumido muita memória.
O que posso fazer para aliviar essa carga?
simplesmente nao carregue!! oq o usuario ta fazendo com tudo isso?
O DDD define que uma informação que faz parte de um Aggregate deve ser acessada somente através de sua raiz.
No meu caso, tabela de preço é a raiz, e os preços devem ser acessados através dela, portanto, ela deve conter todos os preços. Ou estou errado?
Olá ezidio, blz ?
Realmente você tem razão, o acesso sempre deverá ser através da raiz… Nos links abaixo existem outros debates sobre problemas de performance quanto a utilização de DDD + Aggregate.
Porém também concordo com o FernandoFranzini, o que o usuário do sistema irá fazer com toda essa informação disponibilizada de uma vez pelo sistema?
Ezidio,
DDD para fazer consulta? De onde tirou que isso é uma boa idéia?
O mundo conceitual se distancia um pouco do mundo real. Vc não pode carregar tudo isso em uma lista para um usuario da aplicação. Imagine como seria se houvesse mil pessoas fazendo isso ao mesmo tempo? sem chance. Vai minhas dicas:
http://fernandofranzini.wordpress.com/2009/12/16/praticas-de-aplicativos-web/
T+
[quote=henpx]Ezidio,
DDD para fazer consulta? De onde tirou que isso é uma boa idéia?[/quote]
Pois é… mas existe cadastro de tabela de preço tambem, e a tabela de preço contem regras de negócio tambem, algumas até que bem chatinhas.
=]
Então, o que to pensando em fazer:
Criar uma interface que contem todas as operações sobre os preços da tabela (adicionar, remover, recuperar, contar, fazer somas, etc…). Com isso, eu posso criar uma implementação desta interface que delega as operações todas para um banco de dados, e quando eu estiver cadastrando uma nova tabela de preço, que ainda não estará gravada no banco de dados, eu utilizo uma outra implementação dessa interface armazenando os valores na memória.
O que vocês acham?
[quote=ezidio][quote=henpx]Ezidio,
DDD para fazer consulta? De onde tirou que isso é uma boa idéia?[/quote]
Pois é… mas existe cadastro de tabela de preço tambem, e a tabela de preço contem regras de negócio tambem, algumas até que bem chatinhas.
=][/quote]
Sugiro que leia o link que o joaosouza postou sobre CQS (command and query separation). Se não entender isso ( separar regras de consultas) nunca vai entender o que é DDD.
[quote=henpx][quote=ezidio][quote=henpx]Ezidio,
DDD para fazer consulta? De onde tirou que isso é uma boa idéia?[/quote]
Pois é… mas existe cadastro de tabela de preço tambem, e a tabela de preço contem regras de negócio tambem, algumas até que bem chatinhas.
=][/quote]
Sugiro que leia o link que o joaosouza postou sobre CQS (command and query separation). Se não entender isso ( separar regras de consultas) nunca vai entender o que é DDD.[/quote]
Meu amigo, acredito que você não entendeu o que eu quis dizer. Eu não utilizo a tabela de preço para consulta, utilizo a lista de preços dentro dela para validações e cálculos internos da tabela de preço como um todo.
Esse mesmo problema pode acontecer se eu tiver um aggregate “Pedido”, onde um pedido pode possuir uma grande quantidade de itens. O pedido deve realizar o somatório do valor de todos os itens, calcular percentual de rentabilidade, etc… Isso não é consulta, é regra de negócio.
Agora, se continuo equivocado no meu pensamento, por favor, me esclareça.
[quote=henpx][quote=ezidio][quote=henpx]Ezidio,
DDD para fazer consulta? De onde tirou que isso é uma boa idéia?[/quote]
Pois é… mas existe cadastro de tabela de preço tambem, e a tabela de preço contem regras de negócio tambem, algumas até que bem chatinhas.
=][/quote]
Sugiro que leia o link que o joaosouza postou sobre CQS (command and query separation). Se não entender isso ( separar regras de consultas) nunca vai entender o que é DDD.[/quote]
Na minha humilde opinião, a separação não é entre regras e consultas e sim entre operações que alteram o estado do sistema e aquelas que somente retornam informações sobre o sistema sem efetivamente altera-lo.
[quote=esmiralha][quote=henpx][quote=ezidio][quote=henpx]Ezidio,
DDD para fazer consulta? De onde tirou que isso é uma boa idéia?[/quote]
Pois é… mas existe cadastro de tabela de preço tambem, e a tabela de preço contem regras de negócio tambem, algumas até que bem chatinhas.
=][/quote]
Sugiro que leia o link que o joaosouza postou sobre CQS (command and query separation). Se não entender isso ( separar regras de consultas) nunca vai entender o que é DDD.[/quote]
Na minha humilde opinião, a separação não é entre regras e consultas e sim entre operações que alteram o estado do sistema e aquelas que somente retornam informações sobre o sistema sem efetivamente altera-lo.[/quote]
Ola esmirala,
Você esta certo, eu apenas usei o termo consulta para dizer a mesma coisa.
Galera, meu problema ainda persiste.
Não existe nenhuma abordagem para tratar aggregate com listas “gigantes” internamente?
— Mensagem duplicada —
Bom dia!
A solução para isso é rever seu modelo de domínio.
Como você mesmo disse precisa dos dados para fazer calculo.
Se está carregando uma lista de dados, no caso da tabela de preço, para fazer este calculo, seu modelo de domínio não está sendo representado corretamente.
O seu exemplo de Pedido é a mesmo coisa!
Se você tem um valor total a ser calculado e este valor total é um complemento do Pedido, então para evitar consumo de memoria desnecessário crie um objeto que represente este conceito, sendo que seu modelo ficaria algo assim:
class Pedido implement DomainObject{
...
private ValorTotal valorTotal;
private List<Item> items;
...
}
class ValorTotal implement ValueObject{
...
private double value = 0.00;
..
}
Se este pedido tiver muitos itens o melhor a fazer é criar no DAO ou outro padrão de consulta de dados que use, uma solução direta no banco de dados, tipo um “select sum(p.value) from Pedido p”.
Pronto! Resolvido… não precisa ficar percorrendo milhares de itens para fazer um calculo e o melhor, não precisa recuperar no banco milhares de itens para fazer este calculo.
Na ideia do Evans, como ele mesmo disse, não é fazer um modelo engessado, e sim um modelo dinâmico e que possa evoluir de acordo com as necessidades e sempre que tiver um conceito representativo no seu domínio, este deve ser considerado elégível a se tornar um value object, quando não uma entidade.
Outras coisa muito legal que ele diz é: “não brigue com a tecnologia” . Isto porque o mundo real e o mundo virtual é diferente em diversos aspectos e a busca por representar um no outro é uma questão de paciência, persistência e tempo… E não estou dizendo para gastar muito tempo analisando um modelo, e sim que só com bastante casos os conceitos vão se aprimorando em nossa cabeça!
Bom… é isso!
T+
Acho que faltou bom senso nessa implementação, DDD é um bom guia para design, mas não são Dez Mandamentos a serem seguidos a torto e a direito.
Em relação a performance então, quase sempre você vai ter que mexer em algo mais baixo nível, pensando em como a máquina vai fazer um processo, e não como um humano faria. Quase sempre fica feio, e parece um POG, mas não é.
Se precisar também mostrar uma grande lista, provavelmente você precisará de uma técnica chamada paginação
Se não tiver como fazer os cálculos em banco, dê uma estudada no padrão Iterator, e na implementação de mesmo nome dentro do Java.
Se qualquer forma, nunca carregue uma lista/tabela inteira em memória, a não ser que tenha certeza que ela seja muito pequena (relativamente falando).