[mtone]

There's a relevant term called "DDD Trilemma" (I like it because it's easy to find back articles on it). It states that you can't have both a pure, complete and performant domain.

For example, I think what you describe is opting to inject a service to the domain that makes it indirectly talk to the database. In light of the "trilemma", we can imagine it sacrifices a little bit of purity (external dependency, stronger tie to the database schema) in order to keep things simpler -- and nothing wrong with that. In some cases performance could be affected too (ie. if the natural logic might want to update an entity twice during the course of a transaction).

But you still have "completeness" in that you can query your domain as one unit and handle logic within it.

I like that the "DDD Trilemma" acknowledges there is no universal, perfect solution for handling the object-relational mapping problem.

[moring]

I didn't know that term, so many thanks for that. I might add that I always treated performance in a "don't fix it if it ain't broken" way because clean domain code was much more important to me and performance problems tend to show up where you don't expect them anyway. One "escape hatch" I always had was to push operations down into the database layer if they can be solved by more complex queries or stored procedures.