Focus on the needs of the Application first. Design the Classes and Data Model that the Application needs to the extent of having a working end-to-end Application that use Data Pages that represent the points where your Application will interact with the Systems of Record. This will determine the Data Model classes needed for your Process Layer: your Logical Data Model.

Initially, simulate the Systems of Record to verify the working application. Then, encapsulate the complexities of translating between your Application's data model and that of the System of Record by evolving the Data Pages to implement the persistence/integration. Define distinct *-Int-* classes - in the Integration Layer for that System of Record - to model Database Systems of Record or interfaces exchanging SOAP, XML, CSV or other non-JSON messages; define JSON Data Transforms to model JSON messages. 

Classes for your Integration Layer - as well as other rules required for Integration - could be packaged as a Component.

Distinct Data Model classes for the UI Layer are not typically needed. Any presentation layer state that requires a data model would be considered part of the Model of a Model-View-Controller architecture, and its classes should be considered in the same scope as Process Layer classes.

Discussion on this topic was sought from the LSA Data Excellence (Pega 8.4) webinar conducted in July 2020. The webinar and its full set of discussions that arose from it are available at LSA Data Excellence: Webinar, Questions & Answers.