My simple stance here is that the job of a software engineer is to model things in code when building solutions and there is no need to make that explicit in the name of things. Those can be analogues of real world entities (Person, Telephone), conceptual entities (Bank Account, Playlist), programming concepts (Logger, HttpClient), programming strategies (SomethingFactory, SomethingStateMachine), whatever.
Calling something PersonModel is wholly redundant, there is no chance I will ever confuse your file for an actual living human if you simply call it Person.
Similarly I’m often against a .Models namespace or folder, IME it becomes a dumping ground for anything that actually matters. This is particularly destructive I feel, nothing about the project structure actually reflects the domain model of the application despite the ironic insistence on “Model”. Combine the namespace and suffix to thoroughly ruin my day.
Ultimately I feel this all leans into optimising for code creation - you boil down the act to choosing names and structure to simply slapping a meaningless suffix on a class because it doesn’t fit into wrapper or factory or controller or whatever other utility objects you’ve got. No need to review existing models and names, just fire and forget.
But doesn’t everyone do this?
Yes and no, I’ve worked with a lot of people that do this so yes it’s common and ‘established’ in that sense, but I struggle to name libraries or frameworks that do this. I feel there’s often a disconnect between the way people write code and the way they consume it and this is a prime example: maybe if all of your frameworks and libraries were littered with “model” you’d see the pain at the forefront and realise it’s not a great choice.
Are there exceptions?
Of course there are. Firstly, what do I know? I’m coming from a largely .NET enterprise object-oriented mindset, I feel it doesn’t make much sense at all in my neck of the woods but I don’t claim to know everything or everyone’s environments. If it’s idiomatic somewhere, maybe that’s fine? IDK.
More seriously, some concepts and patterns are legitimately named “Model” like “ViewModel” and in those contexts the word Model does have a specific meaning and a pattern you’d expect it to adhere to. A generic “model” implies nothing and is of no use to me like those named patterns/concepts are. A ViewModel serves a view. A Model serves… ???????
Get back to modeling
I do believe that most people use Model when they mean Domain Model - a model of something in their business domain, the “business objects” to use a term which nauseates me. It’s very useful to talk about your domain models verbally and I use that term a lot in speech, but to get a bit facetious with my point here, why don’t you instead try using the suffix “Object” or “Class” or even “File” for a bit and see if that provides you any less value, because I talk about all of those things too but manage to keep them out of my identifiers.
“Model” - it’s what you do, not what you should call things.