It's not that your domain is different, it sounds more like you don't know how to use ORMs. ORMs don't have to manage migrations, they don't have to even write into the database. When dealing with a bad database design, it can be a legitimate tactic to use ORMs in read-only mode and have writes still as hand-rolled SQL. You can do database-first ORMs, as well as code-first, where the database design is king, not the POCO.

> The domain deals with a lot of things that are not in the database.

You can have non-serialized properties. You can even can over-ride serialization/de-serialization of individual properties

> The domain is one of many and deals with just a fraction of what is in the database

You can use different ORMs for different parts of your domain, you could even wrap multiple ORMs in a wrapper repo pattern if you want

> The domain deals with things stored in several databases

As above.

> The database was designed in the 90s and the domain is new

Tons of solutions for this, one easy one is using SQL Views, just ask Claude. The weird thing here is that I've now dealt with this IRL like 5 times and came to the opposite conclusion of you. I found wrapping a bad DB design with an ORM a great first step in fixing it, as the ORM effectively acts as an easy strangler pattern.

> It's not my database so I can't change it

You can still use ORMs, ORMs don't have to manage migrations. Though I feel sorry for you working somewhere you still have a DB guy gatekeeping the database design in 2026.

The point is, every one of your objections are pretty trivially solvable with many mature ORMs, because everyone else had the same problems two decades ago and instead of throwing up their hands and hand-rolling their SQL, the ORM tooling was improved.