Agregados

É exatamente pra cenários mais complexos assim que existem os Domain Services. Quando temos operações que não cabem em uma única entidade, nós abstraímos a operação em uma classe só pra ela.

Fala mestre, então..

Eu resolvi o problema dessa maneira com os domain services. Um questionamento que ficou martelando a minha cabeça era se fazia sentido o Associado e Mensalidade serem um agregado só, sendo o Associado o root? Por que existem uma relação direta entre eles. O associado possui um estado de inadimplência que para estar consistente depende diretamente de sua lista de mensalidades, sendo que, separando mensalidade e associado em agregados distintos dependo de rodar um domain service para deixar esse status consistente e se fossem ambos um único agregado não dependeria do domain service . Existe alguma métrica para saber em qual ponto devo separar agregados mesmo que haja esse tipo de relação entre eles?

Eu separei por que nas minhas pesquisas eu sempre via o exemplo do cliente e ordem de pedido(praticamente em todo lugar na internet esse exemplo). Para saber quando são agregados diferentes uma dica seria que eles devam possuir repositórios diferentes? Não sei se consegui explanar de maneira clara...

Existe alguma métrica para saber em qual ponto devo separar agregados mesmo que haja esse tipo de relação entre eles?

Cara, é bastante subjetivo, mas se um agregado em algum momento pode existir sem o outro, pode ser interessante separar. Mas analisando bem, Mensalidade não existe sem Associado, certo? Sempre que você acessa algo da mensalidade, é referente a algum associado. Então acredito que faça sentido manter o associado como root sim.

Você ainda pode ter um repo específico pra mensalidade que o seu repo de associado usa, pra separar melhor o código. Não precisa unir tudo num lugar só não.