I've found that DDD and a read/write separation of concerns simplifies things greatly. On the write side, the ORM just returns an aggregate, usually based on t

I've found that DDD and a read/write separation of concerns simplifies things greatly. On the write side, the ORM just returns an aggregate, usually based on the PK of the root. Thats's trivial for any ORM. On the read side, simple queries can be modelled with ORM syntax if you're just trying to fetch a graph of existing objects. Complex queries can be returned with raw SQL that map to custom read models. I tend to wrap both styles in integration tests that ensure the query logic doesn't change, and that the actual mappings don't break. Both ORMs and SQL have their usages, and they're not mutually exclusive.