Radice aggregata con molti campi

Question

Radice aggregata con molti campi

#1 da (4 voti)

1

Sto lottando con questo problema da molto tempo.

Diciamo che sto cercando di modellare alcune attività che hanno clienti, aziende, contratti, fatture, ecc. Tutte sembrano essere un buon candidato per la radice aggregata per me. Il problema è che, diciamo che Contract avrebbe un enorme elenco di campi, e molti di loro sarebbero richiesti. Quindi la maggior parte delle volte finisco con una grossa radice aggregata (un sacco di dati, qualche logica e invarianti) con enormi costruttori. Anche se lo romperò in oggetti di valore è solo minimizzando un danno (invece di 20 ho 7 argomenti) e il più delle volte quegli oggetti di valore sono super artificiali, non ha senso un business, sono solo una specie di contenitori di dati.

Il secondo problema è l'aggiornamento di questi dati. Dovrei aggiungere un singolo metodo per aggiornarlo, diciamo UpdateAllThisJunkData (, o scrivere un metodo per ciascuno?

Ritengo inoltre che gli aggregati come questo siano più di tipo CRUD e non abbiano molto a che fare con DDD, ma credo anche che sia necessario mantenere i dati in qualche modo nel sistema anche se non lo usano per elaborare alcuna logica, solo per scopi storici e di visualizzazione (l'utente può prendere decisioni basandosi su tali valori). Dovrei dire di spostare quel tipo di dati su AR o VO diversi, ad es. ContractData?

C'è anche l'opzione che sono paranoico e tutto va bene con la mia AR;)

Gradirei qualsiasi pensiero

domain-driven-design aggregate event-sourcing

posta mgibas 06.11.2015 - 14:47

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design aggregate event-sourcing

Condividi il livello dati per il progetto di outsourcing Come fare a git unire automaticamente numeri di build aumentati? [chiuso]

score 4 · Accepted Answer

Non tutti i dati sono necessari per ogni contesto limitato

Sebbene un contratto possa effettivamente avere un numero elevato di campi, non tutti i campi saranno rilevanti per ogni contesto limitato. Ad esempio, se si dispone di una fattura per un cliente che è stata creata come parte di un contratto, è molto probabile che vi siano informazioni per il contratto che non sono rilevanti per la fatturazione. Quindi, avresti un contesto limitato in cui una fattura ha un riferimento a un contratto, ma dove ci sono pochissimi campi sul contratto perché il processo di fatturazione non ha bisogno di queste informazioni.

Se ritieni che il Contratto sia più simile a un contenitore di dati, sono piuttosto sicuro che sia così. Esiste un contesto limitato in cui sono necessari 20 o più campi da inserire in modo da avere i dati, ma molto probabilmente altri campi dell'applicazione non avranno bisogno di questi campi.

"Richiesto" è relativo

È molto facile dire che un contratto non può esistere senza un enorme elenco di campi, ma sei sicuro che non può? Potrebbe non essere valido eseguire una determinata azione su un contratto se mancano alcuni campi, ma ciò non significa che devono essere presenti quando si crea un contratto.

Consideralo in questo modo: mentre ordini qualcosa da un sito di e-commerce potresti compilare il tuo ordine in diversi passaggi distinti, passando attraverso una serie di schermate per inserire i prodotti, le informazioni di spedizione, le informazioni di pagamento, ecc. .. L'ordine viene salvato tra una fase e l'altra, anche se mancano le informazioni necessarie per completare l'ordine! L'unica differenza è che prima che un ordine possa essere spedito ha bisogno di quell'informazione. Ciò non significa che non possa essere creato .