Ci sono due diversi aspetti nella tua domanda: dove dovrebbe essere il confine nel tuo modello di dominio? e come implementare il tuo modello?
I limiti nel modello
La definizione di un aggregato è:
A cluster of associated objects that are treated as a unit for the
purpose of data changes. External references are restricted to one
member of the aggregate, designated as the root. A set of consistency
rules applies within the aggregate’s boundaries.
Leggendo la tua domanda, sembra che:
- a
Purchase Order ha un ID univoco e questo identifica l'oggetto in modo completamente indipendente dal Contratto. A proposito, questa è una normale pratica commerciale: qualsiasi ordine di acquisto deve essere facilmente recuperato in qualsiasi situazione, anche senza conoscere il contratto (ad esempio, i lavoratori del magazzino che ricevono la spedizione di un ordine non si preoccupano del contesto del contratto).
- Inoltre, tu dici che potresti benissimo aggiungere un'iniziativa all'OP direttamente. Ciò suggerisce che la coerenza del modello non richiede che il Contratto verifichi la coerenza.
Questi fatti suggeriscono strongmente che PO e Initiative potrebbero essere in un aggregato che non include Contract . È necessario confermare questa detrazione, verificando che il contratto non sia necessario quando si modifica l'ordine di acquisto, si aggiunge un'iniziativa o si modifica un'iniziativa. Un'altra domanda utile è che cosa succede agli OP quando il relativo Contratto ottiene uno stato "cancellato" o cancellato.
L'implementazione
Quando parli di idratazione del PO, ecc. stai riflettendo sull'implementazione. Questo è NON qualcosa su cui riflettere WHEN DESIGNING il tuo modello di dominio. Esistono numerosi modelli per implementare un'applicazione per database orientati agli oggetti (ad esempio mappe di identità, caricamento lento, ecc.). Ma prima devi pensare al dominio e comprenderlo bene.
Ad esempio, se sembra che ogni modifica di un ordine di acquisto richiederebbe il controllo incrociato di alcuni massimali del contratto e viceversa, la modifica di alcuni limiti del contratto richiede di verificare in tempo reale che il nuovo valore è ancora al di sopra del valore totale di tutti gli ordini pertinenti, quindi una modifica diretta a un ordine d'acquisto sembrerebbe un po 'rischiosa. Potrebbe quindi essere una buona idea considerare la radice aggregata con il contratto dopo tutto. Troverai sempre soluzioni tecniche per domini e sfide aziendali. Ad esempio, sotto la mega ipotesi di aggregazione una query sul numero di PO potrebbe benissimo restituire l'aggregato corrispondente. Fino a te per incanalare la modifica al PO attraverso il contratto per rafforzare la coerenza. Puoi anche utilizzare il principio del carico pigro per caricare un aggregato ma idratare solo gli oggetti strettamente necessari.
