For the sake of simplicity, let us first assume your "data model" reflects the underlying persistence model, probably a relational model behind it. Then it depends heavily on the size and structure of the overall system how much the data model will be different from the domain model:
in small systems, there will be often only one core application. One starts with creating a small domain model, and the data model will be derived from it, solely for the purpose of persisting the domain model. In such a system, it is unlikely to have difference between the models. In fact, generating one from the other, or boiler plate code for all of them from a common meta source makes sense.
bigger systems may be structured in a way where a common database in the background offers a larger data model shared by different applications or "bounded contexts", each accessing a different part of the system, maybe from a different point of view, but not completely disjoint. Normalization rules and the goal of storing each piece of information in one and only one place then can lead to differences between the data model and a domain model.
Note this is still a simplification, there are many more scenarios possible, like bigger systems using a microservice architecture, where each service is small and has its own persistence model, or bigger systems with a huge, shared domain model layer, where the domain model and data model are guaranteed to correspond to each other by generators. Other scenarios may have (1) a domain model, (2) a data model in client code and (3) a database model, and all three differ to some degree.
So after this length introduction, what am I trying to tell? Well, my point is: if the data model and the domain model should be identical is nothing which is dictated by the mapping strategy.
It is quite the other way round: the overall architecture of the system tells you how the models are structured, and then you pick a suitable mapping strategy.