Sto studiando il DDD in un contesto di sviluppo e sembra che abbia frainteso qualcosa.
In realtà, stavo pensando che un'entità è l'oggetto che può essere conservato su un supporto di archiviazione come un database.
Ma vuol dire che l'entità è la stessa cosa di una riga nel mio database ?
Intendo lì, può esistere oggetti tra le mie Entità e il mio database, come una rappresentazione di una riga di database, che sarà "convertito" nella mia entità aziendale?
But does it mean that the entity is the same thing than a row in my database ?
No, assolutamente no. Il tuo database potrebbe non essere nemmeno un database; ricorda che un REPOSITORY fornisce "l'illusione di una collezione in memoria di tutti gli oggetti di quel tipo" (Evans, capitolo 6). Naturalmente, può supportare questa illusione poiché è una collezione di oggetti in memoria.
I mean there, can it exist objects between my Entities and my database, like a representation of a database row, that will be "converted" to my business entity ?
Sì. Ad esempio, in event-sourcing, le "righe" nel database sono rappresentazioni di "eventi", ognuno dei quali descrive un cambiamento dello stato di un'entità. In tale sistema, si carica l'entità leggendo dal database una rappresentazione della cronologia dell'entità, quindi "riproduce" quella cronologia per ottenere una rappresentazione dell'entità stessa.
But does it mean that the entity is the same thing than a row in my database?
No, non esattamente. Dal punto di vista DDD, un'entità è un elemento del modello di dati del dominio. Fa parte dell'Uzquitous Language. Leggi losttechies post su Entities.
Le righe DB sono rappresentazioni degli stati Entità .
DDD non riporta le relazioni 1-1 tra le righe e le entità DB. Al contrario. Estratti da tali dettagli.
Le rappresentazioni di uno stato potrebbero essere archiviate in righe, tabelle o perché no, in diversi DB. Potrebbero essere memorizzati anche in memoria, file, database NoSQL, ecc.
I mean there, can it exist objects between my Entities and my database, like a representation of a database row, that will be "converted" to my business entity?
Sì, può. Se utilizzare ORM (EF) o semplici POCOS (Row-mapper) sono dettagli di implementazione.
Ho trovato vaughnvernon post per essere molto perspicace. Egli esemplifica l'approccio con EF.
Specialmente questa citazione:
We are going to implement the Product Aggregate using two approaches. One approach uses a Separated Interface with an implementation class, and the other uses a domain object backed by a state object. The whole point of these examples is to stay as far out of Entity Framework’s way as possible.
Tecnicamente DDD non dice molto su come mantenere i dati. Nel libro DDD di Eric Evans, sembra preferire schemi molto semplici senza molti join. Ci sono anche alcuni video in giro con interviste a Evans in cui esalta le virtù dei database NoSQL nel contesto di DDD. Quindi sembra ragionevole concludere che quando fai DDD la maggior parte della tua attenzione dovrebbe essere sulla modellizzazione del dominio e sulla persistenza di quel modello quando necessario nel modo più semplice possibile.
Leggi altre domande sui tag domain-driven-design