When writing an application following Domain Driven Design you're taught to decouple your domain models (i.e. how your business logic is represented) from your persistence logic. In bygone times that was only achievable by maintaining separate domain models and persistence entities. More recently, however, and with the advent of tools such as fluent configuration in ORMs, domain models and persistence entities are often one and the same.
In recent times though I've started to think that domain models used within ORMs are tailored to work with that ORM instead of representing actual domain concepts.
Take for example a school management information system. If you were representing a term (or semester if you live across the big pond) in terms of your domain you might have the following aggregate:
Implement your domain models to be compatible with an ORM without any abstraction though and you start representing your domain in an ORM compatible fashion:
It's then easy to see how even in this extremely simplistic example ORM compatibility starts to take precedence over writing a logical domain model representing business concepts.
In the end, whether this is an impact for your use case is a trade off you should consider along with all of the others. For me, the larger and more complex the application I write, the more likely I am to completely decouple the domain model and persistence layer in order to represent what I am programming as closely as possible.
