Imporre le regole di aggregazione nel dominio di gestione degli acquisti

Question

Imporre le regole di aggregazione nel dominio di gestione degli acquisti

#1 da (1 voti)
#2 da (0 voti)

3

Ho problemi a definire i limiti aggregati (e forse anche la radice aggregata) per applicare la regola di coerenza transazionale. Vorrei prima descrivere il dominio del problema.

Nel nostro dominio abbiamo un progetto che contiene un piano preventivato , che a sua volta contiene centinaia di articoli da acquistare che devono essere acquistati . Alcuni di questi elementi sono selezionati per formare un compito di acquisto . Quando ciò si verifica, l'elemento deve essere spostato dal piano preventivato alla attività di acquisto . Il flusso dell'articolo è importante (deve essere controllato per una revisione successiva), quindi l'elemento deve essere un'entità e avere un identificatore.

Il mio attuale design avrebbe la attività di acquisto come radice aggregata e conoscerebbe tutti i suoi elementi. Sono propenso a lasciare il piano preventivato al di fuori di questo aggregato in quanto contiene molti articoli. Ma poi ho iniziato a dubitare di me stesso.

Vaughn Vernon descrive che un aggregato ben progettato dovrebbe essere "basato su vere regole di business che richiedono dati specifici per essere up- fino alla fine di una transazione di database di successo ". Nel mio scenario l'elemento di acquisto che viene spostato dal piano preventivato a una attività di acquisto designata deve essere rimosso dall'elenco degli elementi nel < em> piano preventivato . Ora, se il mio aggregato non include il piano preventivato e tutte le centinaia di articoli presenti, non posso applicare questa regola. Se lo includo, l'aggregato diventa più grande e dovrà caricare tutti gli piani preventivi (centinaia, forse migliaia) per la convalida per avere successo.

Poiché l'articolo di acquisto è anche un'entità che deve essere tracciabile e modificabile, penso che dovrebbe essere la sua radice aggregata. Quindi l'articolo dovrebbe essere referenziato solo dal suo ID sia dal piano preventivato che dall'attività di acquisto. È corretto?

La domanda principale è: come devo definire i miei confini e radici aggregate per poter applicare la regola di coerenza transazionale in questo dominio?

domain-driven-design aggregate

posta Tuukka Haapaniemi 03.09.2015 - 16:19

fonte

2 risposte

Leggi altre domande sui tag domain-driven-design aggregate

Controller MVC e disaccoppiamento spiegato Architettura a cipolla nell'applicazione client-server

score 1 · Answer 1

Il piano di progetto potrebbe essere un piano aggregato e pianificato e l'attività di acquisto potrebbe essere entità all'interno di quell'aggregato. Il progetto conosce tutti i dati necessari per prendere le decisioni. Ci possono essere un bel po 'di dati, ma puoi utilizzare il lazy loading e le query sql personalizzate per ottimizzare l'utilizzo della memoria e della CPU.

Design alternativo: Il piano pianificato e l'attività di acquisto potrebbero essere aggregati. Si salva un po 'di memoria ma ora è necessario modificare due aggregati contemporaneamente quando si spostano gli elementi tra i due, il che probabilmente significa che si dovrebbe usare la coerenza finale tra i due aggregati. Vedi qui come questo può essere ottenuto .

score 0 · Answer 2

When this occurs, the item should be moved from the budgeted plan to the purchase task.

Sei sicuro? Quella lingua suona davvero strana.

Mi aspetto che un piano di budget si comporti come una lista della spesa. Pianifichi quello che stai per acquistare, e poi quando arrivi al negozio inizi a controllare le cose dalla lista. Si noti che questo è diverso dalla rimozione degli elementi dall'elenco, il che implicherebbe cosa? strappando la lista in pezzi in modo da poter prendere l'oggetto alla fine e buttarlo via.

Tieni presente che poiché l'elenco persiste, arrivi al checkout e hai la possibilità di confrontare il contenuto del tuo carrello con l'elenco.

As the purchase item is also an entity that needs to be trackable and modifiable I think that should be it's own aggregate root.

Quali invarianti l'entità dell'elemento di acquisto deve applicare per sé in questo dominio?