Como modelar a ordem de classificação de muitos para um em duas raízes agregadas

Question

Tomemos o domínio proposto em Design agregado eficaz de um produto que possui vários lançamentos.Neste artigo, Vaughn chega à conclusão de que tanto o Produto quanto o Release devem ter suas próprias raízes agregadas.

Agora suponha que adicionamos um recurso

• Como gerente de lançamento Eu gostaria de poder classificar lançamentos para que Posso criar cronogramas para lançar épicos maiores para nossos usuários

Não sou um PM com uma necessidade específica, mas parece razoável que eles queiram a capacidade de classificar lançamentos na interface do usuário.

Não sei exatamente como isso deve funcionar.É natural que cada versão tenha uma propriedade de pedido, mas a reordenação envolveria a alteração de vários agregados na mesma transação.Por outro lado, se essa informação estiver armazenada no agregado do Produto, você precisará de um método como product.setRelaseOrder(ReleaseId[]) o que parece um dado estranho para armazenar em um local completamente diferente dos Releases.Pior ainda, adicionar uma versão envolveria novamente modificações em dois agregados diferentes!O que mais podemos fazer?ProductReleaseSortOrder pode ser seu próprio agregado, mas isso parece totalmente absurdo!

Então o que fazer?No momento, ainda estou inclinado para a opção deixar o produto gerenciar, mas o que é correto aqui?

Answer 1

Então, o produto e a liberação são ambos ars.O lançamento tem uma associação ao produto via agregado.Você quer obter lista de todas as liberações para um determinado produto ordenado por algo?

Como o pedido é um atributo de agregado, então ele deve ser definido no produto, mas os lançamentos também são ARS e você não deve acessar o repositório de liberação no produto AR (cada AR deve ter seu próprio repositório).

Eu simplesmente faria um lançamentoService que leva o parâmetro ProductID e Order e chamar ReleaserePositive.OleOderedReleasEsforeProduct (ProductId, Order).

Eu também pensaria em separar os contextos, talvez o modelo para apresentação de lançamento seja em outro contexto?No exemplo, produtos AR adicionais, que seriam usados apenas para consultar.

Answer 2

Descobri que, na verdade, é melhor criar um novo raiz agregada (por exemplo, ProductReleaseSorting conforme sugerido) para cada finalidade individual de classificação e/ou pedido.Isto é porque releaseOrder claramente não é realmente uma propriedade do Product, ou seja, algo que tem um significado em um produto por si só.Em vez disso, é na verdade uma propriedade de uma “visão” em um coleção de produtos, e esta visão deve ser modelada por si só.

A razão pela qual tendo a introduzir uma nova raiz agregada para cada visão individual em uma coleção de itens fica clara se você pensar no que aconteceria se você introduzisse pedidos adicionais no futuro, digamos, um "pedido de marketing" ou vários gerentes de produto. deseja manter seu próprio pedido, etc.Aqui, percebe-se facilmente que “ordem de marketing” e “ordem de liberação” são dois conceitos diferentes que devem ser tratados de forma independente, e se várias pessoas quiserem solicitar os produtos com a mesma chave, mas usando pedidos diferentes, você precisará de pedidos individuais. visualizações por pessoa".Além disso, pode ser que existam vários critérios de ordem que se gostaria de ter em conta ao ordenar (um exemplo para o último seria (num contexto diferente) rota mais rápida vs.rota mais curta), tudo isso depende da visão que você tem da coleção e não das propriedades individuais de seus itens.

Se você agora lida com a classificação do Gerente de Produto em um ProductReleaseSorting agregado, você

1. ter uma única fonte de suporte de verdade para o pedido (o AR),
2. o ProductReleaseSorting AR pode impor restrições como a de que dois produtos não tenham o mesmo número de pedido, e você
3. não enfrente o problema de ter que atualizar vários ARs em uma única transação ao alterar o pedido.

Observe que seu ProductReleaseSorting agregado provavelmente tem uma identidade única ("Singleton") em seu domínio, ou seja, todos os gerentes de produto compartilham a mesma classificação.Se, no entanto, todos os membros da equipe gostariam de ter seus próprios ProductReleaseSorting, é trivial apoiar isso dando o ProductReleaseSorting um ID correspondente.Da mesma forma, uma versão mais genérica ProductSorting pode ser obtido por um ID por equipe (marketing vs.gerenciamento de produtos) do repositório.Tudo isso é fácil com uma raiz agregada nova e separada para fins de pedido, mas difícil se você adicionar propriedades aos itens/entidades subjacentes.