Skip to content

Commit d62d15f

Browse files
oblomov-devoblomov-dev
authored
Update runtime.md
1 parent 636fee5 commit d62d15f

File tree

1 file changed

+119
-1
lines changed

1 file changed

+119
-1
lines changed

‎docs/advanced/technical/runtime.md‎

Lines changed: 119 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -31,4 +31,122 @@ In the end, the View & Model are defined independent from the HTTP-Service and w
3131

3232
RAP vs. Model & View decoupled from the (single & generic) HTTP-Service
3333

34-
Let's take a look to the HTTP-Handler that provides us with this flexibility.
34+
Let's take a look to the HTTP-Handler that provides us with this flexibility.
35+
36+
37+
38+
39+
40+
41+
42+
43+
44+
45+
46+
47+
48+
49+
50+
51+
52+
### new
53+
54+
Domain-Driven Architecture with RAP (and contrast to UI-Driven)
55+
56+
**Domain-Driven Design (DDD)** is an architectural approach that models software systems based on real-world business domains. It promotes aligning code with business terminology and processes.
57+
58+
In SAP, the **ABAP RESTful Application Programming Model (RAP)** applies domain-driven principles to build enterprise applications on S/4HANA.
59+
60+
This page explains how RAP embodies Domain-Driven Architecture — and how **abap2UI5 takes a fundamentally different approach**.
61+
62+
---
63+
64+
## What is Domain-Driven Architecture?
65+
66+
Key principles of Domain-Driven Design:
67+
- **Domain Models**: Represent business entities & relationships.
68+
- **Bounded Contexts**: Isolated domain-specific models with clear interfaces.
69+
- **Ubiquitous Language**: Shared business terminology in models & code.
70+
- **Separation of Concerns**: Domain logic separated from UI & infrastructure.
71+
72+
In SAP, this typically translates to:
73+
- CDS Views & Entities as Domain Models.
74+
- Behaviors for domain-specific processes.
75+
- Typed OData Services for structured interfaces.
76+
77+
---
78+
79+
## Domain-Driven Design in RAP
80+
81+
### Domain Models
82+
- Modeled using **CDS Views** (Root & Composite Entities).
83+
- Reflect business concepts like `SalesOrder`, `BusinessPartner`.
84+
- Data model is defined **at design-time** via CDS.
85+
86+
### Behaviors & Processes
87+
- Modeled through **Behavior Definitions** (Managed/Unmanaged).
88+
- Actions like `Submit`, `Approve`, `Cancel` represent domain logic.
89+
- Draft handling, validations, side effects handled by RAP runtime.
90+
91+
### Bounded Contexts & Service Projections
92+
- Service Projections define clear boundaries per domain.
93+
- Typed OData V4 APIs expose domain models & behaviors.
94+
95+
### UI Integration
96+
- Fiori Elements renders UIs based on OData metadata & annotations.
97+
- UI structure is derived from the domain model (Domain → UI).
98+
99+
---
100+
101+
## Limitations of RAP's Domain-Driven Approach
102+
- **Data models are static**: Defined via CDS at design-time.
103+
- **UI reflects the domain model structure**: Flexible adjustments at runtime are limited.
104+
- Dynamic use cases (e.g., changing data schemas at runtime) are not feasible.
105+
- Strong governance ensures stability but reduces runtime flexibility.
106+
107+
---
108+
109+
## Contrast: abap2UI5's UI-driven, Dynamic Approach
110+
111+
In contrast to RAP's domain-first architecture, **abap2UI5 follows a UI-driven pattern** with high runtime flexibility:
112+
113+
### Key Differences:
114+
- **UI5 View Definitions are central**: The UI is designed first, independent of the backend data model.
115+
- **Backend supplies XML Views & ViewModels dynamically**.
116+
- Data models can be **swapped or constructed dynamically at runtime**.
117+
- Technologies like **RTTI (Runtime Type Information)** enable dynamic data handling.
118+
- No dependency on design-time CDS models.
119+
- UI logic and structure are controlled in ABAP at runtime.
120+
121+
### Why is this different from RAP?
122+
| Aspect | RAP (Domain-Driven) | abap2UI5 (UI-Driven, Dynamic) |
123+
|--------|---------------------|------------------------------|
124+
| **Data Model Definition** | CDS Views (design-time) | ViewModel built dynamically in ABAP |
125+
| **UI Definition** | Based on domain model (annotations) | XML View controlled directly in ABAP |
126+
| **Runtime Flexibility** | Limited, strictly typed | High: dynamic ViewModel, RTTI possible |
127+
| **Frontend Rendering** | Fiori Elements SPA builds UI from metadata | Static UI5 shell renders backend-provided View |
128+
| **Typical Use Cases** | Stable, transactional apps | Dynamic UIs, prototypes, tools, flexible CRUD apps |
129+
130+
---
131+
132+
## Summary
133+
134+
- **RAP** applies Domain-Driven principles by strictly defining data models, behaviors, and services at design-time.
135+
- This ensures robust, structured applications aligned with business domains.
136+
- However, it limits runtime flexibility and dynamic UI adaptations.
137+
138+
- **abap2UI5**, in contrast, prioritizes UI-driven development with flexible View & ViewModel handling at runtime.
139+
- Data models can be built or replaced dynamically, allowing agile, backend-controlled UI composition without CDS dependencies.
140+
141+
Both approaches serve different purposes:
142+
- **RAP**: Structured, enterprise-grade transactional apps.
143+
- **abap2UI5**: Flexible, backend-driven UI development for scenarios where dynamic behavior & rapid iterations are key.
144+
145+
---
146+
147+
## Further Reading
148+
- [Domain-Driven Design Quickly (DDD Summary)](https://dddcommunity.org/resources/)
149+
- [ABAP RESTful Application Programming Model (RAP)](https://help.sap.com/docs/abap-cloud/abap-restful-application-programming-model)
150+
- [abap2UI5 Documentation](https://abap2ui5.github.io/docs/)
151+
- [Ubiquitous Language in DDD](https://martinfowler.com/bliki/UbiquitousLanguage.html)
152+
- [SAP Clean Core Approach](https://community.sap.com/topics/clean-core)

0 commit comments

Comments
 (0)