All fine, except how to make the last rule (When there is no more User in the UserGroup, the UserGroup should be deleted from the views.) work with this model?
È un vincolo sulla query eseguita dal modello di lettura per creare la vista.
Ciò potrebbe significare che è necessario aggiornare il modello di lettura per supportare il vincolo. Ad esempio, nella tua implementazione originale, potresti aver supportato la visualizzazione di gruppi di utenti con un Set, in cui ogni gruppo sarebbe stato inserito nel set al momento della sua creazione.
Con il nuovo requisito, il modello di lettura ora deve tracciare l'appartenenza totale. Quindi sostituisci il Set con una mappa, con te usato per tracciare il conteggio degli utenti aggiunti e rimossi dal gruppo. Quando hai bisogno di una vista dei gruppi, enumeri le voci dell'hash per trovare i gruppi che soddisfano il vincolo (subscribedMembers > unsubscribedMembers).
Si noti che questi dettagli si basano esclusivamente sul modello di lettura: il requisito descritto non impone alcuna restrizione sul modello di scrittura. In base al tuo commento su UserGroupMemberLeft , sembra che tu stia cercando di introdurre la fine della vita nel modello.
Come sottolineato da @JDT, alcuni aggregati devono essere responsabili della fine della vita. Quale stato determina se l'eliminazione di un gruppo è consentita? L'aggregato che controlla quello stato è quello che dovrebbe essere responsabile per l'operazione di fine vita, poiché è l'unico che sa se è permesso il ritiro del gruppo.
Non conosco il tuo dominio, ma suppongo che il gruppo stesso contenga lo stato richiesto. Ad esempio, se non ti è permesso di ritirare un gruppo più di una volta, probabilmente è il gruppo che lo sta monitorando. Allo stesso modo, se ti è permesso solo di ritirare i gruppi vuoti, è probabilmente lo stato del gruppo che sta monitorando quello.
Quindi presumo che il gruppo sia responsabile della propria pensione. A questo punto, hai due opzioni a tua disposizione. Uno è un gestore di processi, che osserva i conteggi dei membri e invia un comando per ritirare il gruppo quando osserva che non ci sono membri. A causa della coerenza finale, questo comando potrebbe essere rifiutato, ad esempio se un nuovo membro si unisce al gruppo dopo che è stato lasciato l'ultimo.
Se è necessario ritirare il gruppo in modo coerente rispetto alla transazione, il gruppo si blocca contro ulteriori iscrizioni come parte della transazione quando l'ultimo membro lascia. Ad esempio, se il modello di scrittura sta trasmettendo eventi al modello letto, la partenza dell'ultimo utente genererebbe due eventi, uno che descrive l'uscita dell'utente e un secondo che descrive il ritiro del gruppo.
Poiché il gruppo si blocca quando l'ultimo membro parte, non devi preoccuparti delle condizioni della gara.
Fatto questo, il tuo modello di lettura può utilizzare l'implementazione Set da prima, aggiungere gruppi al set quando vengono creati per la prima volta e rimuoverli quando il gruppo è in pensione.