There are many different things, which are described by the word model. When we say "model," we can think of a scale model of a car, a ship or even a house. Such models represent real-life objects on a different scale and also demonstrate the substantially different level of details. Some models could be quite abstract, like a model of some complex of buildings. Other models, however, can give a more detailed view of what they represent, like scale car models, which are often very accurate. But most of the time, such models are also missing some important features of real cars, like engine, gearbox and sophisticated electronics.

So, models represent some artifact of the real world, but with a narrow purpose. How much space the building would occupy and how high the whole complex would be, is often just enough for a rough model, during the first review stage of the building project. Models do not intend to replicate real life. Instead, they represent some particular aspects of real life in a certain level of detail, depending on the purpose of the model.

Map of the city transport lines would give us a great example.

As you can see, this maps shows the transport links, all stations, and changes. It also indicates some essential geographical aspects, like relative distance to the sea and on which side of the river the stations are located.

At the same time, this map does not show the distance between stations and has no direct resemblance to real geographical locations. To find exactly where stations are located in the city, or how much time you would need to spend traveling from one station to another, you would need another map.

This example demonstrates that a particular model could represent some useful aspect of real life, but could ignore all other elements as not necessary. It does not mean that those neglected aspects aren't important at all, they are not crucial to that particular problem space. Thus, the transport links map solves the problem of orientation for public transport users, and it does it well. But it does not solve the problem of direction on the streets and doesn't need to because it serves a different purpose.

As such, domain models in software also need to represent those aspects of the business domain, which are essential to solving the problem in question. It is sometimes very tempting to put everything we know and, to go further on this slippery path, everything we could assume about the business domain, to our model. But it would add unnecessary complexity to the model and won't help to solve the problem. Even worse, putting too many irrelevant details to the model might broader the implementation scope and mystify the intention that the business people had in mind when specifying problems they wanted to solve.  

Getting back to the Chapter 1 (Why Domain-Driven Design), if the business domain and particular problems we have to solve are in our problem space, the domain model is purely in our solution space. We will be modeling our solution, and those models will be our domain models.