Mi rendo conto che probabilmente è eccessivo per ciò che è un'app client connessa occasionalmente, ma la costruzione delle radici degli aggregati è un bug quando ci si pensa dal punto di vista del cliente.
Allo scopo di fornire la visualizzazione del dominio, diciamo solo che l'intero sistema si occupa di organizzare e modificare le riunioni con i clienti.
Ora, il modello di dominio è impostato correttamente ed è in grado di definirsi correttamente FUORI dalla necessità di interfacciarsi con un altro sistema. Tuttavia, il caricamento di dati client su un sistema esterno può provocare conflitti di dati (aggiornamento, eliminazione, ecc.) Che a loro volta aumentano gli UserAlerts. Ciò richiederà l'intervento dell'utente del cliente per poterlo risolvere. (ad es. Visualizzazione dei due record prima di unirli e salvarli in uno solo).
Quindi, in primo luogo, mi sembra che lo scopo generale del modello di dominio principale sia ben diverso dalla necessità per un utente di risolvere un conflitto di dati. Quindi, in questo senso, mi aspetto che UserAlerts sia separato dall'aggregato della riunione.
Tuttavia, la risoluzione di un avviso dovrà sicuramente essere condotta all'interno di una transazione, poiché l'avviso stesso non dovrebbe esistere senza l'oggetto riunione. Quindi, in questo senso, sembra che abbia senso che l'avviso sia contenuto all'interno dell'aggregato.
Quindi, sono confuso riguardo a questo. Qualcuno là fuori ha modellato una situazione simile? (Ho già una soluzione temporanea, ma vorrei solo sapere cosa pensa la gente sia il modo corretto di fare le cose).