Come fai a sapere se hai diviso il tuo dominio correttamente

Penso che Udi Dahan dia una risposta fantastica a DDD e alla creazione di radici aggregate: link

Come dichiarato da @Malvolio è necessario capire quale problema si sta cercando di risolvere, quindi ha deciso su come la situazione torna al mondo reale. Una volta ottenuto questo, la radice aggregata diventerà chiara ed evidente.

Dicono che l'esperienza è l'insegnante peggiore perché prima fai il test e poi la lezione.

Le decisioni di progettazione vengono ratificate quando il problema cambia (o la comprensione del problema cambia) e non è necessario strappare enormi blocchi di codice e ricominciare da capo.

Naturalmente, ormai è troppo tardi.

Il meglio che puoi fare in modo proattivo è porsi due domande:

1. Il mio design rappresenta davvero il mio problema, in quei concetti basilari fondamentali nel problema, lo spazio è rappresentato da concetti fondamentali, fondamentali nel design e le caratteristiche contingenti del problema sono secondarie anche al design?
2. Che cosa succede se ho torto? Cosa succede se alcune delle ipotesi che ho fatto nel progetto si rivelano sbagliate o smettono di essere nel giusto? Cosa succede se un dipendente è gestito da un appaltatore? Una fattura può essere vuota? È solo un nuovo test unitario o è un progetto importante?

Il mio suggerimento: non progettare le radici di aggregazione, mantenendo il refactoring del modello e le radici di aggregazione si mostreranno. Durante lo sviluppo del sistema, noterai che alcune entità correlate vengono sempre modificate insieme, quindi sai che appartengono alla stessa radice di aggregazione.