Non ne sono sicuro, ma penso che tu non stia andando per il verso giusto.
Il dominio è il campo in cui lavora il tuo cliente, ma ciò che è più importante è come vedono quel dominio . Ci sono scuole di giliardi là fuori, ma non funzionano tutte allo stesso modo. Non hanno tutte le stesse regole, procedure o gergo.
Quindi devi scoprire come funziona il tuo cliente: mappare i comportamenti. Per esempio. uno studente si iscrive: quale effetto ha su tutta la scuola e tutti i suoi dipartimenti?
Devi anche indicare dove le stesse parole iniziano ad avere significati diversi, perché di solito è un segno che hai trovato un altro contesto limitato. Per esempio. uno studente è qualcosa di diverso rispetto a un insegnante, piuttosto che al reparto contabilità.
È del tutto normale avere per esempio 2 classi di studenti, con proprietà diverse o addirittura le stesse in 2 contesti limitati. Concentrati sul comportamento, non sui dati; non normalizzarsi prematuramente.
Se hai più contesti limitati, generalmente vuoi essere in grado di comunicare tra loro. Il più delle volte, ciò si ottiene inviando eventi di dominio (ad esempio StudentEnrolledInCourseEvent) su un bus di messaggi come RabbitMQ. Puoi quindi elaborare questi eventi sull'altro lato come preferisci.
Se si dispone di una mappa dei comportamenti e contrassegnati con contesti diversi, è possibile iniziare a considerare ciò che deve essere coerente dal punto di vista della transazione; quei gruppi saranno i tuoi aggregati.
Non riesco a pensare ad un esempio relativo alla scuola in questo momento, ma considera una macchina con weels. Puoi controllare le ruote dell'auto attraverso l'api dell'auto, ma non direttamente, perché vuoi evitare di avere una ruota che punta a sinistra e un'altra che punta a destra.
Tieni presente che molte entità sono aggregati per conto proprio; non tutti gli aggregati sono entità "annidate".
Spero che questo sia stato di aiuto.