DDD - Come evitare i confini aggregati sovrapposti?

Question

DDD - Come evitare i confini aggregati sovrapposti?

#1 da (1 voti)

2

Recentemente ho iniziato a leggere il libro di Evan sul DDD, e ho deciso di provare ad applicare alcuni dei principi di quel libro su un contesto limitato di un progetto su cui ho lavorato.

Il contesto di interesse riguarda la pianificazione degli appuntamenti e degli appuntamenti. Presenterò alcuni dei requisiti aziendali, oltre al modello attuale.

Abbiamo dipendenti, appuntamenti e stanze. Un appuntamento può avere al massimo 1 dipendente per ruolo, ad esempio 1 consulente, 1 medico. Questi dipendenti iniziano e finiscono la loro parte dell'appuntamento in un momento diverso. Ad esempio, un consulente può essere presente da x1 a y1, e un medico può essere presente da x2 a y2 (questi possono sovrapporsi o essere disgiunti). L'appuntamento è considerato per iniziare al più presto xe terminare al più tardi y. Un appuntamento può anche avere solo 1 paziente. Un appuntamento deve svolgersi in una stanza. I dipendenti non possono avere appuntamenti che si sovrappongono (per quanto riguarda i loro orari di inizio e fine). Un appuntamento non può aver luogo in una stanza se quella stanza è occupata per un altro appuntamento.

Questo è il modello che ho trovato:

Oltre alle invarianti precedenti, queste regole aziendali devono essere rispettate: un paziente può avere solo 1 appuntamento programmato in un dato momento (presuppone che ci sia un attributo di stato in Appuntamento).

Il modello dovrebbe supportare i seguenti casi d'uso:

Pianificazione di un appuntamento.
Aggiornamento dell'ora di inizio / fine programma di un appuntamento
Assegnazione di un dipendente diverso a un appuntamento
Aggiunta / rimozione di appuntamenti da un appuntamento

Ho difficoltà a definire gli aggregati, le loro radici e i loro limiti. Dalle limitazioni date, penso che sia abbastanza ovvio che l'aggregato DailySchedule deve comprendere gli oggetti valore Availability e AppointmentSchedule. Tuttavia, l'appuntamento deve comprendere anche AppointmentSchedule al fine di mantenere invariata la presenza di un solo ruolo di dipendente per ciascun appuntamento. Inoltre, Room e Patient devono entrambi includere Appointment per mantenere invarianti.

Supponendo che l'invariante del paziente possa essere modellato come regola di una politica aziendale / oggetto, ciò lascia comunque DailySchedule e Appointment che condividono un riferimento a un oggetto valore, senza passare per la sua radice aggregata.

Mi sembra che questo modello non consenta limiti di aggregazione chiaramente definiti. Stavo considerando di esporre i SERVIZI per ciascuno dei casi d'uso, che si estenderebbe tra i confini aggregati e manterrebbe gli invarianti da lì. Sono interessato a sapere se c'è qualche altra soluzione, forse più elegante / semplice a questo problema.

domain-driven-design domain-model aggregate

posta Stefan Rendevski 27.04.2018 - 14:16

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design domain-model aggregate

Modello di dominio o servizio in un contesto MVC Un'app può avere più "sottodomini" in DDD?

score 1 · Accepted Answer

Un buon punto di partenza per te è il Evoluzione di un modello di Yves Reynhout, in cui descrive la modellazione di pianificazione degli appuntamenti per l'assistenza sanitaria.

Potresti anche voler esaminare la discussione di Greg Young sui sistemi di magazzino . Il sommario è questo: se hai un modo ragionevole per rilevare e segnalare un conflitto di pianificazione nei tuoi dati, potresti non necessariamente aver bisogno di impedire che le violazioni si verifichino.

Un approfondimento che mi ha aiutato a capire questo è che l'ordine che i messaggi arrivano non è una garanzia di correttezza . Udi Dahan, in Condizioni di gara non esistono , osserva

A microsecond difference in timing shouldn’t make a difference to core business behaviors.

Ecco un messaggio che dice che il Dr. Frankenstein dovrebbe essere nella stanza A dalle 10:00 alle 11:00; ecco un altro messaggio che dice che dovrebbe essere nella stanza B dalle 10:30 alle 11:30. È chiaro che i due messaggi non sono coerenti, ma non sappiamo quale sia giusto - in particolare, potrebbe già esserci un messaggio che annulla l'appuntamento "sbagliato", non lo abbiamo ancora visto.

In molti casi, quello che stiamo veramente cercando è qualcosa di simile alle soluzioni che Greg Young descrive in Stop Over Engineering ; prima intensificare i problemi con gli esseri umani, quindi lavorare sull'identificazione dei problemi che sono abbastanza semplici da consentire l'automatizzazione delle soluzioni.

I sistemi che vincolano eccessivamente per prevenire conflitti spesso infliggono esperienze deludenti agli utenti. Si è verificato un errore di immissione dei dati, ma prima che possiamo immettere i dati corretti per questo appuntamento, il sistema interrompe tali attività e insiste affinché l'errore venga corretto. Inoltre, correggere quell'errore potrebbe essere complicato.

Se tenga presente che il ruolo di un sistema di pianificazione è quello di identificare e risolvere i conflitti, piuttosto che prevenirli, potresti scoprire di avere molta più libertà nella progettazione dei tuoi aggregati.