Skip to content


Jan Koštejn edited this page Sep 18, 2019 · 2 revisions



Model is the first and the most important piece of the whole building - model is foundation of that building. That's why it's in the bottom of that building picture.
You define all the entities and fields in this solution and other solution components that are somehow connected to ability to store data in CDS.

Components that we include in model solutions:

  • Entities
  • Icons (for entities)
  • Connection roles
  • Security roles


Functional units packed together are called feature solutions in our architecture. For example 'SalesProcesses' could be one feature solution, that contains multiple sales processes to support your sales application.

Components that we include in model solutions:

  • Web resources
  • Plugin assemblies
  • Workflows


These solutions are the last ones. They're the last 10% that the customer sees and that's why they need to be perfect. Make sure that you take special care working on these.

Components that we include in model solutions:

  • App modules
  • Canvas apps
  • Sitemap
  • Forms
  • Views
  • Ribbon diff
  • Icons
  • Dashboards
  • Visualizations
  • Business rules (workflows)

Why ModelFeatureApp Architecture?

The reason for creating these three layers is to leverage solution layering and make deploy easier than before.


Bridges are there if you need to connect two (or more) buildings together. You don't want to reference the buildings between themselves because that would require all buildings to be deployed. That's why we have these components in different solution and we call this solution bridge.


Not every component can be easily put into one of these...
I can imagine situation where you want to include ribbon diff into the feature solution for example.
We will get into situations, where it's not easy to decide. Be sure to bring someone senior to the discussion.

You can’t perform that action at this time.