Riferimento oggetto vs riferimento per ID in aggregati DDD

Question

Nel corso Pluralsight Domain-Driven Design Fundamentals, c'è un esempio di come prende forma la progettazione di un aggregato. L'esempio comprende gli appuntamenti del paziente in una clinica. L'appuntamento ha relazioni ad es. da un medico o da una sala d'esame. E l'esempio è preceduto da un'analisi che conclude che l'appuntamento non deve essere una radice aggregata per Doctor and ExamRoom. E un passo nell'evoluzione del design sta passando dall'appuntamento avente riferimenti a oggetti Doctor ed ExamRoom, a contenere gli ID primitivi di queste altre entità, DoctorId ed ExamRoomId. Essi motivare questo cambiamento dicendo: "Semplicemente compresi gli ID dei concetti relativi, piuttosto che i riferimenti agli oggetti siamo in grado di garantire che la creazione e la modifica appuntamento ha un impatto minimo sul nostro sistema quando persistiamo nostro appuntamento"

La mia prima domanda: si tratta di un modello di progettazione comune? Se lo capisco correttamente, si generalizza a qualcosa di simile: Se l'oggetto A si riferisce all'oggetto B, ma l'operazione su A non dovrebbe mai comportare l'esecuzione di modifiche su B, quindi fare riferimento ad esso con il suo id, non con B stesso. È qualcosa che consiglieresti?

La mia seconda domanda: ha qualcosa a che fare con DDD? Intendo il fatto che l'appuntamento non dovrebbe essere una radice aggregata del medico, non significa che non possa contenere riferimenti a oggetti o mi manchi qualcosa?

Answer 1

1. Penso che questo sia un modello di progettazione comune, almeno nell'universo DDD. Evans dice in DDD:

La radice è l'unico membro dell'aggregato che gli oggetti esterni sono autorizzati a tenere i riferimenti a

Se si utilizzano alcuni ORM come Hibernate, avrete forse avete occuparsi del caricamento lento per far fronte a strutture dell'oggetto profondamente collegate che hanno riferimenti a oggetti. Alcune persone considerano pigro il caricamento di un pattern anti.

Dai uno sguardo allo this QA per comprendere meglio il concetto di aggregati. Personalmente sono convinto che i confini aggregati chiaramente definiti migliorano la tua architettura.

2. Se si implementano i limiti di aggregazione, il tipo di appuntamento probabilmente non avrà riferimenti diretti a un medico.

UPDATE: Vaughn Vernon parla rules that spell out the current consensus view of DDD leaders on the style of aggregates (vedi parte II):

[DDD] afferma che un aggregato può contenere riferimenti alla radice di altri aggregati. Tuttavia, è necessario tenere presente che questo non fa posizionare l'aggregato di riferimento all'interno del limite di consistenza dello uno di riferimento. Il riferimento non causa la formazione di solo uno, l'intero aggregato.

E continua:

Se si modifica più istanze in un'unica transazione, è può essere una forte indicazione che i vostri confini consistenza sono sbagliate. Se è così, è probabilmente un'opportunità di modellazione mancante; un concetto del tuo linguaggio ubiquitario non è stato ancora scoperto sebbene stia agitando le mani e urlando contro di te (vedi Parte I).

Nella mia comprensione, l'Appuntamento non deve contenere riferimenti diretti ad oggetti ad altre radici aggregate come il Dottore.