Within this context, the Model represents the domain objects needed to express the business logic supporting the requirements inherent to the application. It's here that all of the use cases are represented as real-world abstractions and a well-defined API is made available to be consumed by any kind of delivery mechanism, such as the web.

Regarding traditional applications, all of the logic to interact with a database or middleware is implemented in the Model. However, the Model (the M in MVC) should expose functionalities (in terms of the business) that are easy to understand. We should also avoid building anemic models that only allow for interacting with the database and are difficult to understand for the rest of the team working on the project.

Once this part of the application has been coded, we should ideally be able to create any UI that allows the users to interact with the Model. Furthermore, since UIs can defer from each other (mobile, web, and desktop apps), the Model should be agnostic to all of them.

In a perfect world, an isolated team would be able to build this part of the application, but in real life, this assumption is entirely wrong. Interaction with the team in charge of building the GUI is required, in order to create an effective Model that is able to address all of the business requirements and expose a comprehensive API.