3

In DDD we say that the domain Entity is not a representation of the database model/entity. We also say that to correctly extract the domain model from the application, the domain model is not supposed to have any information about the way it is persisted or the way it is returned to the client.


The problem I have is that when dealing with most ORM's or database abstractions, we are required to annotate the database entity with some database specific annotations, thereby breaking the rules.


Does this mean that we are supposed to create one entity for the domain and another one for the persisting?


I am new to this and not sure what the correct approach is.

George
  • 3,757
  • 9
  • 51
  • 86

1 Answers1

4

A domain model tends to be a rather encapsulated affair. As such domain objects are not good candidates when it comes to ORM entities.

If your domain entities look like data containers such that they would be able to serve as ORM entities, if adorned with some attributes, then your domain is at best not encapsulated and at worst an anemic model.

In my opinion you would typically end up with a domain model and some form of data-oriented ORM model.

As somewhat of an aside:

Once you start asking what your ORM brings to the table you may want to look into how much you would be losing by foregoing the ORM and using some other raw/lower level data access technology. There may even be some performance gains to be made. If I ever have a say in the matter I do not use an ORM.

Eben Roux
  • 12,983
  • 2
  • 27
  • 48