The term domain model, although indeed being known from before, got widely acknowledged after it was mentioned in the Martin Fowler's book Patterns of Enterprise Application Architecture by Addison Wesley, 2003. Here is how Fowler defines the term in P of EEA (https://martinfowler.com/eaaCatalog/domainModel.html):

This definition is quite short and concise. And still, somehow it got very wrong if you look at various links in Google if you search for "domain model." If you have done the same as I did and searched for the phrase, you've found out that the majority of found images, and most of the links, lead to something that we can consider as data models or entities models. Such models visualize entities, data fields with types and relations between entities. In best cases, links are attributed by domain terminology as well like attends or consist of, and in some rare cases, we can find class diagrams that show some methods.

What we see in case of entities or data models are so-called anemic models. As the term suggests, such models only express the system state and know nothing how this state changes and what operations are being done in the system. Usually, if you look at implementations of such systems, you will find out that everything the system does is some manipulations on data. New entities are being created, new relations are being made, and fields in entities get changed. That's all.

There are a couple of reasons why anemic models became popular. First, guidelines to visualize domain models in UML suggested that things that are getting envisioned are conceptual classes. These classes represent real-world entities and their properties. In UML, such models would include items (entities) with attributes (fields), their associations (relations) and actors. Hence, there is no place for behavior in conceptual classes. The next reason is that the idea of conceptual classes somehow got lost and these UML models became the only domain models, where domain behavior was considered not significant.

Getting back to Fowler, in the Bliki article about anemic models (https://martinfowler.com/bliki/AnemicDomainModel.html) he clearly defines this way of modeling systems as an anti-pattern. In addition to described above, anemic models often tend to be implemented entirely by database operations. Models that consist of objects with relations resemble closely with relational models, and therefore relational databases are most frequently used to persist such objects. The association between an anemic domain model and its state in the database is so tight that they become siblings and cannot be distinguished from one another.

Very often if you find a system with an anemic model as the domain model, you will have a hard time understanding what the system does since all you see in the code is SQL and calls to run it. And if you ask people who work with the system about where you can find the implementation of their model, they most probably will point directly to the database. There is also an opinion that anemic domain models are useful in case the application has little or no behavior and such model serves perfectly fine as a persistence model; I would argue that in such case there is no reason to call it a domain model. Data models are perfectly fine since they serve the purpose of persistence. However, there is no real justification for presenting data models as domain models, since these are two different things.