I m studying DDD in a development context, and it seems that I've misunderstood something.
Actually, I was thinking that an Entity is the object that can be persisted on a storage support like a database.
But does it mean that the entity is the same thing than a row in my database ?
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 ?
But does it mean that the entity is the same thing than a row in my database ?
No, absolutely not. Your database might not even be a database; remember that a REPOSITORY provides "the illusion of an in-memory collection of all objects of that type" (Evans, chapter 6). It can, of course, support this illusion by in fact being an in-memory collection of objects.
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 ?
Yes. For instance, in event-sourcing, "rows" in the database are representations of "events", each of which describes a change of the state of an entity. In such a system, you load the entity by reading from the the database a representation of the history of the entity, and then "replay" that history to get a representation of the entity itself.
But does it mean that the entity is the same thing than a row in my database?
No, not exactly. From the DDD perspective, an Entity is an element of the domain data model. It's part of the Ubiquitous Language. Read losttechies post about Entities.
DB rows are representations of the Entities states.
DDD does not state relationships 1-1 between DB rows and Entities. Quite the contrary. Abstract yourself from such detail.
The representations of a state could be stored in different rows, tables or why not, in different DBs. They could be stored in memory too, files, NoSQL DB's, etc
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?
Yes, It can. Whether to use ORMs (EF) or mere POCOS (Row-mappers) is implementation details.
I found vaughnvernon post to be very insightful. He exemplifies the approach with EF.
Especially this quote:
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.
Technically DDD doesn't really say much about how to persist data. In the DDD book by Eric Evans, he seems to prefer very simple schemas without a lot of joins. There's also some videos floating around with interviews of Evans wherein he extolls the virtues of NoSQL databases in the context of DDD. So it seems reasonable to conclude that when doing DDD most of your attention should be on modeling the domain well and persisting that model when needed in the simplest way possible.
