Raiz agregada e muita eficiência de dados

5

É mais um cenário, mas não é de todo improvável. Digamos que eu tenha um Warehouse Aggregate Root (AR) que é usado para gerenciar o estoque de produtos. O Produto em si é um AR em um contexto limitado diferente (BC), mas neste BC é representado apenas por um id. No Warehouse eu posso adicionar um novo produto (deve ser único), posso removê-lo e posso atualizar estoque. É claro que posso comunicar o estoque de um produto e talvez até manter o fluxo de entrada / saída de um produto.

O problema é que você pode facilmente chegar a centenas ou milhares de produtos. Assim, para qualquer ação wareohuse, você terá que carregar tudo, mesmo que essa ação não use todas essas informações. É altamente ineficiente.

Uma solução que consegui pensar é "quebrar" o AR do warehouse em objetos especiais para diferentes ações. Mas isso significa que não temos mais um AR e estamos de volta a uma solução semelhante a CRUD. Ainda mais, o AR foi dividido não porque o domínio o necessita, mas porque os detalhes técnicos dele precisam.

Parece que você pode fazer o DDD até um certo ponto, depois disso você faz o CRUD ou compra um servidor MUITO MAIOR e caro.

O que você acha? Podemos ter DDD e eficiência quando muitos dados estão envolvidos?

    
por MikeSW 12.01.2013 / 10:01
fonte

1 resposta

0

Can we have both DDD and efficiency when lots of data is involved?

Sim, no entanto DDD não é totalmente livre de restrições técnicas, especialmente em arquiteturas mais modernas. Um agregado pode ser considerado como um limite de consistência transacional e não simplesmente uma representação pura do domínio de negócios. Ao pensar em um agregado como um limite de consistência, ele pode ser projetado de forma a otimizar os casos de uso correspondentes.

Em seu cenário, ter um grande Warehouse agregado resultará na sobreposição de limites - as informações de estoque de um produto não têm restrições de integridade associadas a outros produtos. O problema pode ser que o agregado Warehouse contenha comportamento para gerenciar o estoque, além de servir como um tipo de âncora para o seu modelo de domínio. Uma solução seria mudar o comportamento para um ProductInventoryAggregate . Outra poderia ser introduzir consistência eventual.

Dê uma olhada em Design agregado efetivo de Vaughn Vernon para saber mais sobre isso. No geral, porém, vejo a tensão que você observa entre concentrar-se no domínio puro, por um lado, mas considerando as restrições técnicas do outro. Isso não é um conflito muito grande, pelo menos para mim, já que vejo o valor central do DDD como sendo os padrões estratégicos e não os táticos.

    
por 22.01.2013 / 20:14
fonte