Root aggregato e un sacco di efficienza dei dati

Question

Root aggregato e un sacco di efficienza dei dati

#1 da (0 voti)

5

È più uno scenario, ma non è affatto esagerato. Diciamo che ho un magazzino Aggregate Root (AR) che viene utilizzato per gestire le scorte di prodotti. Il prodotto stesso è un AR in un diverso contesto limitato (BC), ma in questo BC è rappresentato solo da un id. Nel magazzino posso aggiungere un nuovo prodotto (deve essere unico), posso rimuoverlo e posso aggiornare lo stock. Certo, posso comunicare lo stock per un prodotto e forse anche mantenere il flusso in / out per un prodotto.

Il problema è che puoi facilmente raggiungere centinaia o migliaia di prodotti. Quindi, per qualsiasi azione di wareohuse dovrai caricare tutto anche se quell'azione non utilizzerà tutte quelle informazioni. È altamente inefficiente.

Una soluzione che potrei pensare è quella di "infrangere" l'AR del magazzino in oggetti speciali per diverse azioni. Ma questo significa che non abbiamo più un AR e siamo tornati a una soluzione simile a CRUD. A maggior ragione, l'AR non è stato diviso in quanto il dominio ne ha bisogno, ma perché i dettagli tecnici ne hanno bisogno.

Sembra che tu possa fare DDD fino a un certo punto, dopo di che vai CRUD o acquista un MIGLIOR GRANDE e un server costoso.

Che ne pensi? Possiamo avere sia DDD che efficienza quando sono coinvolti molti dati?

domain-driven-design performance efficiency

posta MikeSW 12.01.2013 - 10:01

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design performance efficiency

Flusso di lavoro Git - avvisare un principiante C'è stato un lavoro formale che paragonasse la facilità di manutenzione a livello di linguaggio di programmazione?

score 0 · Accepted Answer

Can we have both DDD and efficiency when lots of data is involved?

Sì, tuttavia DDD non è completamente privo di vincoli tecnici, specialmente nelle architetture più moderne. Un aggregato può essere considerato come un confine di consistenza transazionale e non semplicemente una pura rappresentazione del dominio aziendale. Quando si pensa a un aggregato come limite di consistenza, può essere progettato in modo da ottimizzare i casi d'uso corrispondenti.

Nel tuo scenario, avere un grosso aggregato di Warehouse comporterà confini sovrapposti: le informazioni di magazzino di un prodotto non hanno vincoli di integrità associati ad altri prodotti. Il problema potrebbe essere che l'aggregato Warehouse contiene un comportamento per la gestione dello stock oltre a fungere da ancoraggio per il tuo modello di dominio. Una soluzione sarebbe spostare il comportamento a ProductInventoryAggregate . Un altro potrebbe essere quello di introdurre un'eventuale coerenza.

Dai un'occhiata a Effective Aggregate Design di Vaughn Vernon per ulteriori informazioni al riguardo. Nel complesso, tuttavia, vedo la tensione che osservate tra concentrarsi sul dominio puro da un lato, ma considerando i vincoli tecnici dall'altro. Questo non è troppo conflitto, almeno per me, dal momento che considero il valore centrale del DDD come i modelli strategici non tattici.