Modellazione delle relazioni uno-a-molti mediante Domain Driven Design

1

Questa domanda è più di una domanda generale su come modellare relazioni uno-a-molti semplici usando le collezioni: una modifica di una voce di elenco dovrebbe riflettersi nella versione dell'aggregato che la contiene?

Il dominio riguarda la pianificazione delle riunioni (come in Outlook). Ho un'entità della riunione, che può avere più partecipanti. Un partecipante può accettare / rifiutare le richieste di riunione. La riprogrammazione di una riunione annulla tutte le conferme dei partecipanti.

Ho pensato a due modi per modellarlo.

Opzione 1 L'aggregato della riunione conterrà un elenco di partecipanti in cui ogni partecipante ha un ID del partecipante e uno stato (accettato / negato). Il problema qui è che ogni comando Accetta o Nega, per uno specifico partecipante, incrementa la versione della riunione, il che significa che due partecipanti entreranno in una condizione di competizione se provano ad accettare la richiesta di riunione in base alla stessa versione originale. Sebbene ciò possa essere risolto rileggendo il documento della Riunione e riprovando il comando Accetta, è piuttosto fastidioso considerare quanto spesso ciò potrebbe accadere. Un altro approccio è quello di ignorare la versione della riunione quando si esegue il comando Accetta, ma questo introduce un nuovo problema: cosa succede se, dopo aver inviato le convocazioni di riunione, la riunione è stata riprogrammata? In questo caso non possiamo permetterci di ignorare la versione del Meeting, perché questa volta la versione DOES rappresenta una versione reale che dovrebbe essere considerata. A proposito, è una buona pratica ignorare la versione in alcuni dei comandi e non in altri?

Opzione 2 Estrarre un aggregato di partecipazione da Riunione. La partecipazione avrà MeetingId, ParticipantId e Status. Avrà anche una sua versione. In questo modo, quando il partecipante X accetta la richiesta di riunione, solo la relativa partecipazione sarà modificata e il resto verrà lasciato intatto. E, al momento di riprogrammare la riunione, verrà pubblicato un evento "Riunione riprogrammata" e un gestore di eventi risponderà ripristinando tutti gli stati delle Partecipazioni su "Non accettato", indipendentemente dalla versione corrente. Da un lato questo sembra logico, nel senso che la versione di una riunione non dovrebbe essere incrementata solo perché qualcuno ha accettato / negato la sua richiesta. D'altro canto, modellare la partecipazione come aggregato autonomo non mi sembra molto giusto, perché non ha alcun significato al di fuori del contesto dell'incontro.

Ad ogni modo, mi piacerebbe avere un feedback su questo e vedere i vari approcci a questo problema.

    
posta Amir Shitrit 22.08.2017 - 08:31
fonte

1 risposta

2

Non penso che questo problema sia limitato al DDD, sembra più un problema di modellazione generale, ma comunque.

L'opzione 2 non è male, e rende il "modello mentale" già esplicito: un cambiamento dello stato di partecipazione conta come un cambiamento della riunione, semplicemente perché non fa parte dell'entità. Tuttavia, se stai cercando una soluzione più semplice, usa "Opzione 3": cerca di evitare l'utilizzo dell'attributo di versione (e se ne hai uno per motivi tecnici, ignoralo per questo caso d'uso).

Quando una riunione viene riprogrammata, perché non creare una nuova entità di riunione , con un nuovo ID di riunione? L'interpretazione di una riunione riprogrammata come una riunione diversa (solo con lo stesso ordine del giorno e una serie di partecipanti) è un punto di vista perfettamente valido e si assicurerà di poter assegnare correttamente qualsiasi risposta richiesta riunione all'entità riunione corretta, in modo indipendente dall'ordine in cui vengono restituite le risposte. Ad esempio, se un incontro è stato programmato per la prima volta lunedì, e poi riprogrammato per martedì, quando qualcuno riconosce la partecipazione per l'incontro martedì, e successivamente rifiuta di partecipare al lunedì, puoi facilmente gestire le risposte, poiché le gestisci semplicemente come risposte a diversi incontri - nessun attributo di versione richiesto.

In caso di modifiche diverse (come l'agenda o l'insieme di persone invitate o la posizione), si invia una notifica ai partecipanti, ma presumo che non si desideri modificare automaticamente lo stato delle conferme di partecipazione. Nel caso qualcuno ti invii un'altra risposta alla stessa riunione e cambi il suo stato di partecipazione - che qualsiasi partecipante può fare in qualsiasi momento, anche quando la riunione stessa non è cambiata - conta la risposta più recente.

Nota: nel caso in cui la riunione non abbia modificato un attributo di versione non ti sarebbe stato d'aiuto né elaborare più risposte per la stessa riunione dallo stesso partecipante. Le persone potrebbero prima riconoscere la partecipazione e poi ritrattare di nuovo la risposta, senza che il sistema invii loro una nuova richiesta o senza alcuna modifica alla "entità dell'incontro" in mezzo. Quindi hai bisogno di qualcosa con una strategia di "ultima risposta conta" con o senza un numero di versione.

    
risposta data 22.08.2017 - 10:25
fonte

Leggi altre domande sui tag