Affects Version/s: 1.0.0ALPHA1
Fix Version/s: 1.0.0ALPHA1
We may want to reconsider the naming of things in ODM projects. I know the term "entity" is heavily overloaded but I think there might be a misunderstanding here of what @Entity refers to in the ORM. The ORM @Entity actually means a (relational) database entity (entity relationship diagram, etc...) not the "DDD" entity, of course there are many similarities.
I don't feel that comfortable with the possibility of half a dozen different "EntityManager"s, especially if they represent entirely different storage paradigms.
Remember, @Entity does not really mean "DDD entity". An EntityManager is not a "DDD entity manager" It is part of the infrastructure (persistence), not of the domain model.
Do we want X different "EntityManager"s? When considering that @Entity actually refers to a relational database entity, it would make more sense to call these things @Document in the ODM projects, since that is what they're stored as. Then we could instead use the term DocumentManager, and not EntityManager for the ODM projects.
I realize that this confusion comes from the fact that many think "entity" = "DDD entity" but that is not the case. @Entity in the ORM refers to a relational database entity just like @Column refers to a relational database column.
So my vote currently absolutely goes for @Document and DocumentManager to keep things consistent. Of course, a mongo and a couch project can both have a DocumentManager, that is fine, both storage paradigms are documents.