Il ritaglio a cascata da una radice aggregata attraverso l'intero aggregato non ha senso

1

Basato sullo stesso esempio per questa domanda .

All'interno di Pro ASP.Net MVC 4 di Adam Freeman, c'è una discussione su aggregati e radici aggregate con un semplice sistema di aste. Ci sono membri che fanno offerte, oggetti che sono offerti e offerte. L'autore afferma che ci sarebbe un aggregato di Item e Bid con Item come root aggregato. L'autore menziona quindi che le radici di aggregazione possono essere utilizzate per eseguire una eliminazione a cascata, che per questo esempio significa che se un elemento viene eliminato, tutte le offerte sugli articoli vengono eliminate. Questo ha senso. Il problema è che le offerte appartengono solo all'elemento / aggregato di offerte e non a un aggregato di membri / offerte. Se elimini un membro del sistema che fa offerte, sembrerebbe ragionevole che anche tutte le loro offerte vengano eliminate. Tuttavia, non posso farlo senza "spezzare" l'aggregato. Inoltre, non posso semplicemente ottenere un elenco di membri delle offerte.

Il mio livello di confusione, dato quanto semplice è l'esempio, mi rende un po 'preoccupato.

Questo è solo un cattivo esempio, il membro / offerta potrebbe essere un aggregato valido invece e c'è un certo livello di arbitrarietà nel rendere la scelta dei tuoi aggregati che è accettabile finché si fa una scelta, c'è un modo per avere i modelli appartengono a più aggregati o mi manca qualcosa?

P.S. La risposta nella domanda che ho linkato afferma che lo sviluppo guidato dal dominio è solo molto complicato, ma non entra in dettagli sufficienti su come è complicato e perché l'ingannevolezza induce confusione e come tale rimangono ancora le mie domande a riguardo. p>     

posta Lawtonfogle 21.04.2014 - 20:30
fonte

1 risposta

5

Due contesti limitati possono fare riferimento allo stesso oggetto. Ma solo uno controlla la durata di vita dell'oggetto.

L'offerta appartiene direttamente all'asta BC. Un libro che consiglio a molte persone è Modellazione Java a colori con UML fornisce un grande set di strumenti per aiutare con modellazione di dominio.

La modellazione basata sul colore classifica gli oggetti del dominio in quattro archetipi: Persona / Luogo / Cosa, Ruolo, Descrittore e Momento / Intervallo.

Sono andato avanti e indietro sulla mappatura dei concetti nel libro con concetti DDD. Pensando in particolare a un'euristica per determinare BC e Radici aggregate basate su Archetypes.

Quello che so è che Membership e Aste sono due BC separati (nel tuo esempio). Il processo di gestione dell'iscrizione non ha nulla a che fare con la gestione delle aste (a parte il fatto che i membri creano / fanno offerte sulle aste. A parte questo, sono due sistemi separati

Un'asta è un esempio di un archetipo Moment-Interval, si verifica in un dato periodo di tempo (quindi è un intervallo). Off of the Auction sono diversi ruoli: il Banditore, il ItemForAuction e, eventualmente, il WinningBidder. Questi ruoli sono assegnati agli archetipi Persona / Luogo / Cosa.

Per esempio c'è una singola parte nel sistema che mi rappresenta Mike Brown. All'interno del sistema, l'entità Mike Brown potrebbe avere diversi ruoli ad essa associati. Un ruolo sarebbe Membro (dal Membership BC) un altro potrebbe essere Banditore (se ho deciso di mettere un oggetto per l'asta) un altro potrebbe essere Bidder (se offro all'asta). L'importante è che indipendentemente dal ruolo che interpreto nel sistema, i dati e le funzionalità associati a quel ruolo sono isolati. Pensa ai ruoli come decoratori o cappelli che le persone indossano a seconda di quello che stanno facendo.

Se ho in mano l'entità Mike Brown. Posso chiedere all'entità "Quali ruoli hai" o "Hai il ruolo di X" e l'entità dovrebbe essere in grado di rispondere. Quindi posso dire, Mike Brown dammi il tuo ruolo di banditore. Dal ruolo di banditore dovrei avere operazioni come CreateAuction, CancelAuction, ListActiveAuctions, ListCompletedAuctions. In altre parole, il ruolo è il motore del sistema.

Ricorda che ho detto che l'asta è un esempio dell'archetipo Moment-Interval. Questi rappresentano eventi o periodi significativi all'interno del tuo dominio. Un altro concetto associato a un Moment-Interval è quello che viene chiamato Successors. Ad esempio, un'offerta è un successore di un'asta. Un'offerta esiste solo nell'ambito di un'asta specifica (ad esempio, un'offerta è parte dell'aggregato dell'asta).

Se l'utente o il membro che ha creato un'offerta viene rimosso dal sistema, ciò non annulla il fatto che sia stata effettuata un'Offerta. (Non più di Divorziare tua moglie nega che tu avessi dei figli insieme, la moglie non fa più parte del tuo aggregato di Famiglia, ma i bambini sono moltissimi ... ignoriamo il fatto che ora i bambini appartengono a due aggregati della Famiglia).

Quello a cui mi sto proponendo come ipotesi è che per ogni Moment-Interval, c'è un attore principale che sarebbe l'archetipo Role. Ad esempio, un banditore è l'attore principale per l'asta M-I. Lui lo crea. Gli altri attori vi partecipano. Sono propenso a dire che l'attore principale per un M-I sarebbe la radice Aggregate, tranne per il fatto che una singola entità Role può partecipare a più M-I.

Quindi l'attore principale è una FABBRICA per un M-I e controlla la durata ma lo stesso M-I sarebbe il candidato per una radice Aggregate. In questo caso, l'asta è una radice di aggregazione. E i suoi successori, ruoli, descrittori e PPT fanno parte del suo aggregato.

L'appartenenza come parte di un contesto limitato separato non dovrebbe avere un accesso diretto alle offerte o alle aste. Cancellare un socio per me in realtà termina l'abbonamento M-I (impostando una data di fine sull'iscrizione). E ogni altra logica implicata nell'assicurare che l'utente non abbia accesso. Il membro esiste ancora, ma è inattivo. Le sue offerte storiche sono ancora lì. Tutti sono felici.

    
risposta data 22.04.2014 - 00:54
fonte

Leggi altre domande sui tag