It also happens in web developments. So often. Webservice data model should not be conditioned by UI. It make it really unflexible and hard to scale.
In terms of web developemnt, in MVC pattern, C (Controller) is the facade in charge of transforming any business data model into a DTO. Such DTO's are neither designed for UI. They are a summary of the real data. Unbinded from database sessions.
However you are working at V (view) facade, so you probably will need your own data model. Oriented to the UI. It's somehow a wrapper or a composite model. This model should be the one you persist in your database. I would not store webservice datamodel because then you are strongly binding your App to that Webservice and its current version. In further versions of the API, model may change and you will need to refactor your APP model again. Too much overlapping.
In your case I rather prefer to implement Transformers that translate webservices responses into my UI Datamodel and persist this last (if needed).
If any entity of webservices datamodel is valid for UI with no translation, then I would persist it too. As it is. For example, master data.
Adapt the info to your own needs, don't tie yourself to a model that can change overtime and will force you to understand those changes in deep. A good plan of translation will prevent you from data model changes and it will make easier for you to deal with these changes. It also can prevent your App from crash because these data model changes.
Should we be creating the database schema first and then use same database schema for client and server and design our DTOs accordingly?
In my opinion, don't do that.
2 applications 2 data models 1-N translators
Final design would be something like this
Persistente Layer: ORM
Business layer: ORM entities
- Controllers: consume ORM entities and transform these into DTO's. DTOs are like webservice data model.
- Webservices client: consumes DTO
- Driver layer: Transform DTO into App's data model.
- App's business layer: App's data model
- App's UI: consume App's data model through App's business layer.
If your app uses directly Webservices DTO you are bound to it for good or bad. If you design DTO thinking in client-side, will be hard to reuse it for another clients.
Like we say here: Let app to cooke the data and transform it into anything else. Leave alone server.
However if you are sure that wont be any other client consuming your webservices, then client app can just use DTO's.
Finally, dead-lines, budget and resources have the last word ;-). My propuse is the ideal scenario.