Differenza tra un'entità e un aggregato nella progettazione basata su domini

Question

Per favore qual è la differenza principale tra entità e radici aggregate nella progettazione orientata al dominio. Ad esempio, nel framework di entità, a che cosa servono gli aggregati se posso garantire le entità di integrità dei dati?

Answer 1

La definizione è abbastanza semplice:

• complessivo: Fondamentalmente un gruppo di oggetti, che creano un chiaro riferimento all'aggregato radice, di modo che quando si fa riferimento la radice, è possibile garantire l'integrità degli aggregati nel complesso.

Aggrega è un modello in Progettazione guidata da domini. Un aggregato DDD è un cluster di oggetti dominio che possono essere trattati come una singola unità. Un esempio può essere un ordine e i relativi elementi pubblicitari, questi saranno oggetti separati , ma è utile trattare l'ordine (insieme alla sua riga elementi) come un singolo aggregato.

Un aggregato avrà uno dei suoi oggetti componente la radice aggregata. Qualsiasi riferimento dall'esterno dell'aggregato deve essere indirizzato solo alla radice aggregata . La root può quindi garantire l'integrità dell'aggregato nel suo complesso.

Gli aggregati sono l'elemento di base del trasferimento della memorizzazione dei dati - è la richiesta per caricare o salvare interi aggregati. Le transazioni non devono superare i limiti aggregati .

DDD Gli aggregati vengono talvolta confusi con le classi di raccolta (elenchi, mappe, ecc.). Gli aggregati DDD sono concetti di dominio (ordine, visita clinica, playlist ), mentre le raccolte sono generiche. Un aggregato spesso contiene collezioni multiple, insieme a campi semplici. Il termine "aggregato" è comune e viene utilizzato in vari contesti diversi (ad esempio UML), nel qual caso non si riferisce allo stesso concetto di aggregato DDD .

• Entity: In un contesto modello di dati, descrive la struttura dei dati indipendentemente dalla forma memorizzata.

L'EDM affronta le sfide che nascono da avere dati memorizzati in molte forme. Ad esempio, si consideri un'azienda che memorizza i dati nei database relazionali , file di testo, file XML, fogli di calcolo e report . Ciò presenta sfide significative nella modellazione dei dati, nella progettazione delle applicazioni e nell'accesso ai dati. Quando si progetta un'applicazione orientata ai dati, la sfida consiste nel scrivere codice efficiente e gestibile senza sacrificare l'accesso efficiente ai dati, l'archiviazione e la scalabilità. Quando i dati hanno una struttura relazionale, l'accesso ai dati, la memorizzazione e la scalabilità sono molto efficienti, ma la scrittura efficiente e manutenibile del codice diventa più difficile. Quando i dati hanno una struttura a oggetti, i trade-off vengono annullati: la scrittura di codice efficiente e gestibile viene al costo di un accesso, archiviazione e scalabilità efficienti dei dati.Anche se è possibile trovare il giusto equilibrio tra questi compromessi, nuove sfide sorgono quando i dati vengono spostati da un modulo all'altro. Il modello di dati delle entità risolve questi problemi descrivendo la struttura dei dati in termini di entità e relazioni che sono indipendenti da qualsiasi schema di archiviazione. Ciò rende irrilevante la forma memorizzata dei dati alla progettazione e allo sviluppo dell'applicazione. Inoltre, poiché le entità e le relazioni descrivono la struttura dei dati in quanto è utilizzata in un'applicazione (non il suo modulo memorizzato), possono evolversi man mano che l'applicazione si evolve.

La definizione può variare, quelli definiti da Martin Fowler e Microsoft. Spero che questo chiarisca la differenza però.

Answer 2

Dal punto di vista del design guidato dal dominio DbContext è l'implementazione di UnitOfWork e uno DbSet<T> è l'implementazione di un repository.

Questo è il punto in cui contrastano DDD e EntityFramework. DDD suggerisce di avere un repository per radice aggregata, ma EntityFramework ne crea uno per entità.

Quindi, che cos'è una radice aggregata?

Supponiamo di disporre di un social network e di avere entità come post, Mi piace, Commento, Tag. (Credo che si possano immaginare le relazioni tra queste entità) Alcune delle entità sono "Radice aggregata"

Per trovare le radici aggregate cerco di trovare quali entità non possono vivere senza l'altra. Ad esempio, Mi piace o Commento non possono vivere senza un post. Allora Post è una radice aggregata e abbiamo bisogno di un PostRepository o trasformare l'entità Post in un repository (la famosa collezione come interfaccia). Le operazioni CRUD per Comment e Like (così come per il Post) dovrebbero rimanere su questo repository.