Typical Application Layers
- Data Layer – Non-volatile data persistence, likely to be a SQLite database but could be implemented with XML files or any other suitable mechanism.
- Data Access Layer – Wrapper around the Data Layer that provides Create, Read, Update, Delete (CRUD) access to the data without exposing implementation details to the caller. For example, the DAL may contain SQL statements to query or update the data but the referencing code would not need to know this.
- Business Layer – (sometimes called the Business Logic Layer or BLL) contains business entity definitions (the Model) and business logic. Candidate for Business Façade pattern.
- Service Access Layer – Used to access services in the cloud: from complex web services (REST, JSON, WCF) to simple retrieval of data and images from remote servers. Encapsulates the networking behavior and provides a simple API to be consumed by the Application and UI layers.
- Application Layer – Code that’s typically platform specific (not generally shared across platforms) or code that is specific to the application (not generally reusable). A good test of whether to place code in the Application Layer versus the UI Layer is (a) to determine whether the class has any actual display controls or (b) whether it could be shared between multiple screens or devices (eg. iPhone and iPad).
- User Interface (UI) Layer – The user-facing layer, contains screens, widgets and the controllers that manage them.

Each of these layers represents an individual Solution Folder
.
And each Layer
should also be a different ClassLibrary(Portable)
(see Encapsulation)
Also worth reading in this documentation:
Encapsulation, Separation of Responsibilities, Polymorphism
Taken from Xamarin Developer Guide - Achitecture
I also found some more info here.