You are right when saying that the model should not contain anything off-topic and should contain its data "tightly". However, this has nothing to do with persistence or any implementation-specific models.
The domain model is what you would use to explain your system to someone who has no idea about your programming language or frameworks. In best case, you can use it for communication with non-programmers.
Based on the domain model you can develop your data model which, in turn, describes what you are persisting and how. You wouldn't include any transitive/calculated data here but possibly database-specific IDs and things like that.
Note that those two are merely the analytical base for your class model/diagram. The classes you have can, but don't necessarily need to reflect everything from the other two models.