Although this is technically possible, it is usually not necessary to have a special representation of domain objects for the presentation layer.
Sometimes it may seem to you that at the presentation level it is required that several objects be combined together (for example, displaying information about two users participating in a chat). In such cases, you can define a wrapper that will bind the required entities together.
However, in my experience, such a combination is rarely required and has a price: the presentation level is “waiting” for all related data, even if parts of this data could be shown to the user (for example, information about one user can be displayed immediately, but information about another user retrieved from the server). This reduces the perceived responsiveness of the application.
In general, for a client application, the domain object schema is typically derived from user interface specifications. Therefore, if you find that you are considering a separate representation of domain objects for the presentation level, it is very likely that one of the following design problems is already present in the application:
- The domain objects used in the application are the same as those used to exchange data with the server.
- Applicaiton requirements have evolved, but domain objects have not changed accordingly.
You always want the network layer to be separate from the rest of the application. This includes circuits that are used when exchanging data with the server. If your domain objects satisfy the restrictions set by the server API, but do not meet the requirements of the presentation layer, then it is best to introduce the "transfer" logic between the network layer and the rest of the application.
If application requirements have arisen, but domain objects have not been updated accordingly, instead of having a separate presentation for the presentation level, it is best to simply review the design and update the entire application in accordance with current requirements.