4 ms·

>ORMs being a forcing function for domain modeling is enough benefit for me that it outweighs all of their obvious limitations. That was a surprising take! I

by Kon5ole 3mo ago

>ORMs being a forcing function for domain modeling is enough benefit for me that it outweighs all of their obvious limitations. That was a surprising take! I know only a few ORM's but it seems they end up just adding another layer of DTO objects that are entirely separate from the domain classes anyway. So best case the ORM is just a detour for a good domain model. Worst case it creates a weird database-contaminated domain model that's hellish to maintain. So I would't say ORMs force domain modeling, or even help. Are you perhaps thinking of a particular stack where the ORM is just one part of it?

Exoristos 3mo ago
Why is your database so different from your domain?
- wuiheerfoj 3mo ago
  I doubt domain logic would ever be in 2NF. My domain logic certainly doesn’t have pivot tables of IDs for join lookup
- Ntrails 3mo ago
  Most commonly ime the application domain may only be some small fraction of the database which is designed/optimised for a much broader dataset.
- Kon5ole 3mo ago
  >Why is your database so different from your domain? Usually it's due to one of these: - The domain deals with a lot of things that are not in the database. - The domain is one of many and deals with just a fraction of what is in the database. - The domain deals with things stored in several databases. - The database was designed in the 90s and the domain is new. - It's not my database so I can't change it. (Even for greenfield systems I don't think it's generally desirable that the database matches the domain model.)
  - mattmanser 3mo ago
    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.
    - webstrand 3mo ago
      That doesn't sound at all like any ORM I've ever used. I've struggled in the past because The ones I've used are actively hostile to laying out data in the database in a way not proscribed by the ORMs philosophy. Heck of the ORMs I've used, one didn't support parameterized joins and the other didn't support joins at all. --- It's not usually a DB guy gatekeeping, it's that multiple apps use the same database so layout changes are costly.
      - Izkata 3mo ago
        Except for the "multiple ORMs" part which is a level above it, it applies to the only one I've used extensively: Django for python. It has standard defaults, but just about everything overridable, and because models are python objects you can add methods or properties for extra data. There's even ways to define your own field types (the "serialization/de-serialization of individual properties"), which a decade ago people were using to provide json fields through libraries long before it was officially supported. ...and Django was like this 15 years ago when I first started using it. The core design hasn't changed, it just sounds like most other ORMs don't really know what they're doing.
KellyCriterion 3mo ago
Mh, in NHibernate when properly modelled, your Domain classes usually match the database/tables, so there is no need to have additional DTOs
mexicocitinluez 3mo ago
> I know only a few ORM's but it seems they end up just adding another layer of DTO objects that are entirely separate from the domain classes anyway. Entity Framework in particular has come a long way in this regard. Particularly owned & complex entities, value converters, etc. https://learn.microsoft.com/en-us/ef/core/modeling/ https://learn.microsoft.com/en-us/ef/core/modeling/ > Worst case it creates a weird database-contaminated domain model that's hellish to maintain. CQRS is good for this because it forces you into using a different write and read model. My write models are domain objects and my read models are DTOs that feed the UI and via projection I can shape them without issue.

by Kon5ole 3mo ago

Exoristos 3mo ago

Why is your database so different from your domain?

wuiheerfoj 3mo ago
I doubt domain logic would ever be in 2NF. My domain logic certainly doesn’t have pivot tables of IDs for join lookup
Ntrails 3mo ago
Most commonly ime the application domain may only be some small fraction of the database which is designed/optimised for a much broader dataset.
Kon5ole 3mo ago
>Why is your database so different from your domain? Usually it's due to one of these: - The domain deals with a lot of things that are not in the database. - The domain is one of many and deals with just a fraction of what is in the database. - The domain deals with things stored in several databases. - The database was designed in the 90s and the domain is new. - It's not my database so I can't change it. (Even for greenfield systems I don't think it's generally desirable that the database matches the domain model.)
- mattmanser 3mo ago
  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.
  - webstrand 3mo ago
    That doesn't sound at all like any ORM I've ever used. I've struggled in the past because The ones I've used are actively hostile to laying out data in the database in a way not proscribed by the ORMs philosophy. Heck of the ORMs I've used, one didn't support parameterized joins and the other didn't support joins at all. --- It's not usually a DB guy gatekeeping, it's that multiple apps use the same database so layout changes are costly.
    - Izkata 3mo ago
      Except for the "multiple ORMs" part which is a level above it, it applies to the only one I've used extensively: Django for python. It has standard defaults, but just about everything overridable, and because models are python objects you can add methods or properties for extra data. There's even ways to define your own field types (the "serialization/de-serialization of individual properties"), which a decade ago people were using to provide json fields through libraries long before it was officially supported. ...and Django was like this 15 years ago when I first started using it. The core design hasn't changed, it just sounds like most other ORMs don't really know what they're doing.

KellyCriterion 3mo ago

Mh, in NHibernate when properly modelled, your Domain classes usually match the database/tables, so there is no need to have additional DTOs

mexicocitinluez 3mo ago

> I know only a few ORM's but it seems they end up just adding another layer of DTO objects that are entirely separate from the domain classes anyway. Entity Framework in particular has come a long way in this regard. Particularly owned & complex entities, value converters, etc. https://learn.microsoft.com/en-us/ef/core/modeling/ https://learn.microsoft.com/en-us/ef/core/modeling/ > Worst case it creates a weird database-contaminated domain model that's hellish to maintain. CQRS is good for this because it forces you into using a different write and read model. My write models are domain objects and my read models are DTOs that feed the UI and via projection I can shape them without issue.