<@U0C1NM397>: Let me be little verbose. A sore sub...

# random

[masted]

@mbickel: Let me be little verbose. A sore subject for me. 😆

But it always struck me as odd that I would have three "models" (DB, ORM, business) ...

Probably you are not required to have this at all. Such granularity (in a healthy case, smells are not considered in the next reasoning) is the tool and approach to manage a complexity where the problem is required such complex solution. There is no any well-defined silver bullet, but cases and domains represented through a design.
From the theory we know that a system which solves the problem must have a complexity that is superior over the complexity of the problem.
All that is beyond this thesis called a design. From such point of view an engineering is a discipline that provides a method to define minimal problem and synthesize minimal solution of this problem.
So if your problem is well-defined and this problem is not require such granularity there is no any reason to have and maintain such complexity over a project.
But! There is always a need to manage an overhead complexity of the solution(that comes from the theory), and there is a place where patterns and heuristics ( about which @konsoletyper said ) come to play.
Although you don't need such complexity like a different model definitions in a most of projects. There is still a place for tricks that let things be a simple in a long term run. Layered architecture is such trick.