Tell us what you think

We want to create the best possible experience for our learners. Your feedback helps us to improve the experience for everyone.

SAP Learning Journey

Introducing Domain Modeling in SAP Cloud Application Programming Model

Objectives

After completing this lesson, you will be able to:

Describe domain modeling in SAP Cloud Application Programming Model

Introducing Domain Modeling in SAP Cloud Application Programming Model

Watch this video to learn about Domain Modelling.

The goal is to:

Keep your domain models clean, concise, comprehensible by

Factoring out technical aspects Separating Concerns, for example.

Fiori Markup
Authorization
Persistence

… in same or different files or projects

Intrinsic Extensibility

Project-level

→ Reuse and Extend

SaaS-level

→ Dynamic Extensibility

SAP Cloud Application Programming Model follows two major paradigms

A declarative paradigm using CDS to capture knowledge about problem domains, and

A service-centric paradigm, with widespread usage of Services, Events and Queries.

Core Data Services(CDS)

CDS is our universal modeling language to capture static, as well as behavioral aspects of problem domains in conceptual, concise, and comprehensible ways, and hence serves as the very backbone of SAP Cloud Application Programming Model.

Best Practices in Domain Modelling

Describe Model Reuse in Domain Modelling

Model Reuse

Reusability has several benefits as seen in the image

Concise and comprehensible models
Foster interoperability between all applications
Proven best practices captured from real applications
Streamlined data models with minimal entry barriers
Optimized implementations and runtime performance

The programming model provides the option to define our own reusable objects called aspects as well as provides some common aspects that can be reused.

Aspects :

Aspects are the reusable models that can be defined ones and then reused in other entities. Aspects allow factoring out cross-cutting or technical concerns into separate models or files,which generally facilitates keeping core domain models clean and comprehensible.

Sometimes, domain models may as well be exposed for reuse in other projects The SAP Cloud Application Programming Model is shipped with a prebuilt model named common and it provides common aspects and types ready for reuse. It is recommended to take advantage of using the provided common types and aspects.

Reusability provides many benefits like making the models concise and comprehensible by applied classic conceptual modeling methods and also fosters interoperability between all applications and optimize implementations and runtime performance. It will make use of proven best practices captured from real applications .

Common Aspects :

The cuid, managed, and temporal are the three aspects conveniently built in and ready to be used. The common aspects are declared by "using" statement.

Aspect cuid is a shortcut to add a universally unique primary key to your definitions.

Aspect managed is used to add the four audit dimensions created by ,created at data,latest changed by and changed at

Aspect temporal enables temporal data, which allows maintaining information relating to past, present, and future application time. This aspect basically adds two elements, validFrom and validTo, to the entity. It also adds a tag annotation that is recognized by the built-in support for temporal data. This built-in support covers handling date-effective records and time slices, including time travel.

Common Types :

In addition to the common aspects the programming model offers common types, These are countries, currencies, and languages. All three of them are implemented in the same manner. the declaration is similar to the common aspects by "using".

Introducing Localization in Domain Modelling

Localizationrefers to adapting your business application to different languages to cater to specific regional markets. This is important for anything that is visible in the UIs.

Localizationis split into two categories,

localization for static content

This is achieved by externalizing all your text literals into separate text bundle files that we call the internationalization files, or in short, i18n files.

You need to maintain a separate i18n file for each language that you'd like to support.

In these i18n files, we store the actual static text as key and value pairs. Your code can then refer to the respective keys as we see here in this picture.

localization for dynamic content

This is achieved by marking the attributes that need to support multiple languages with a special keyword called "localized", this then creates a text table for each entity which has attributes defined as "localized"

Dynamic content that depends on the data that is stored in our persistence service.

The attributes that need to support multiple languages need to be marked with a special keyword called "localized", as we see here. In this case a text table is created for the entity.

Next lesson