© grafvision/Shutterstock.com
Domain-driven Design mit dem SAP Cloud Application Programming Model

Gemeinsame Sprache in der SAP-Welt


In den letzten Jahren hat sich Domain-driven Design zu einer weithin etablierten Vorgehensweise bei der Konzeption und Umsetzung komplexer Systeme entwickelt. Dieser Artikel stellt das SAP Cloud Application Programming Model (CAP) überblicksartig vor und geht anhand einer Beispielanwendung auf die Kernkonzepte von CAP und ihren Bezug zu Domain-driven Design ein.

Eric Evans machte Domain-driven Design (DDD) in seinem 2003 erschienenen Buch „Domain-Driven Design: Tackling Complexity in the Heart of Software“ erstmals großflächig bekannt. Der Ansatz des DDD verfolgt das Ziel einer interdisziplinären Modellierung durch Integration von Entwicklern und Fachexperten in ein einheitliches und standardisiertes Vorgehen. Damit soll die sprachliche Kluft zwischen Entwicklern und fachlichen Domänenexperten überwunden werden, um sich gemeinsam auf die eigentliche Geschäftslogik konzentrieren zu können. Das letztendliche Ziel ist eine qualitativ höherwertige Software sowie ein besserer Erfüllungsgrad der Anforderungen. DDD basiert auf drei einfachen Grundprinzipien:

  • Der Fokus des Entwurfs liegt auf der Fachlichkeit und der Fachlogik.

  • Der Entwurf komplexer fachlicher Zusammenhänge basiert auf Domänenmodellen.

  • Es gibt eine enge und ständige Zusammenarbeit zwischen Domänenexperten und Entwicklern.

Für die Beschreibung von DDD wurden allgemeine Begriffe wie Context, Model, Ubiquitous Language oder Bounded Context sowie für die Domänenmodellierung spezifische Begriffe wie Entity, Value Object oder Domain Event eingeführt. Für eine detaillierte Einführung in DDD sei an dieser Stelle auf das Buch von Eric Evans [1] verwiesen. Der vorliegende Artikel legt den Fokus auf die technische Umsetzung von DDD mit dem SAP CAP.

Das SAP CAP Model ist ein offenes, plattformagnostisches Framework von Sprachen, Bibliotheken und Werkzeugen für die domänengetriebene Entwicklung von Cloud-native Enterprise-Anwendungen. Für viele Anwendungsfälle und wiederkehrende Aufgaben bietet das Framework nützliche Best-Practice-Lösungen, ohne dabei die Offenheit und Flexibilität zu verlieren. SAP CAP unterstützt Domain-driven Design, indem der Fokus auf die Modellierung von Problemdomänen gelegt wird, um die Zusammenarbeit zwischen Domänenexperten und Entwicklern zu vereinfachen. Für den Einstieg in CAP bietet sich die offizielle Dokumentation [2] an.

SAP CAP basiert auf zwei grundlegenden Ansätzen, nämlich einem deklarativen Ansatz der Domänenmodellierung und einem Service-orientierten Ansatz, mit dem alle aktiven Teile einer Anwendung als Services in Form von Pure Functions im Sinne der funktionalen Programmierung implementiert werden. Daten sind demgegenüber den REST-Prinzipien folgend stets passiv.

Domain-driven Design mit SAP CAP

Die Kernkonzepte von CAP sind denen von DDD (wie Entities, Value Objects, Services und Events) sehr ähnlich. Außerdem unterscheidet CAP stark zwischen aktiven Services und passiven Daten, wodurch es beispielsweise keine Instanzmethoden für Entitäten gibt. Für einige DDD-Konzepte wie Repositories, Aggregates oder Factories gibt es zwar keine direkte Abbildung in CAP, sie können allerdings mit anderen Kernkonzepten von CAP indirekt realisiert werden.

Wo liegen die Daten?

Core Data Services (CDS) sind eine Sammlung von domänenspezifischen Sprachen und Notationen zur Definition und Abfrage von semantischen Datenmodellen und stellen das Herzstück von CAP dar. Das Spezielle an CDS ist, dass SAP auch bei anderen Plattformen und Produkten wie HANA und ABAP mit entsprechenden Variationen auf dieses Konzept zur Datenmodellierung setzt. CDS sind also für SAP-Entwickler nichts Neues und wurden deshalb auch für SAP CAP sowohl zur Datenmodellierung als auch zur Definition von Services und Annotations eingeführt. CDS für CAP bestehen aus den folgenden Sprachen und Notationen:

  • CDL (CDS Definition Language): eine menschenlesbare Sprache für die Definition von Modellen

  • CQL (CDS Query Language): eine auf SQL basierende und sie erweiternde Abfragesprache

  • CSN (CDS Schema Notation): kanonisches, dem JSON Schema ähnliches Format zur Repräsentation von CDS-Modellen als Plain-JavaScript-Objekte

  • CQN (CDS Query Notation): kanonisches, dem JSON Schema ähnliches Format zur Repräsentation von CQL-Abfragen als Plain-JavaScript-Objekte

  • CXN (Core Expression Notation): Spezifikation von Ausdrücken innerhalb von CDS-Definitionen oder -Abfragen als Plain-JavaScript-Objekte

Die Persistenzschicht einer CAP-Anwendung wird von einem CDS-Datenmodell abgeleitet. CDS sind an SQL angelehnt, um Domänenmodelle deklarativ zu beschreiben, und erlauben deshalb ein direktes Mapping nach SQL, was CAP mit dem relationalen Modell kompatibel macht. Durch Erweiterungen wie Associations oder Path Expressions kann mit CDS stärker dokumentenorientiert gearbeitet und auf JOINs großflächig verzichtet werden, was auch eine einfache Verwendung von NoSQL-Datenbanken möglich macht.

Allerdings ist davon abzuraten, CAP als weiteres ORM Framework zu verstehen. Anstatt Objektgraphen automatisch zu laden, werden Daten unter Verwendung von CQL deklarativ gelesen bzw. geschrieben und in einem Result Set aus puren REST-Daten zur Verfügung gestellt.

Das Transaction Handling in CAP ist denkbar einfach – das gesamte Processing eines Events passiert immer in einer Transaktion. Implementiert man einen Event Handler, läuft der Code garantiert immer innerhalb einer Transaktion. Spring-Boot-basierte CAP-Anwendungen sind darüber hinaus in das Transaction-Management von Spring Boot integriert. Somit können sowohl die Spring-Annotation @Transactional als auch TransactionTemplate verwendet werden.

SAP CAP unterstützt die Datenbanken SAP HANA und SQLite out of the box. Mit CSN2JPA [3] bietet SAP auch ein Modul zur Generierung von JPA-Entitäten aus deklarativ beschriebenen CDS-Modellen, um Daten in JPA-kompatiblen Datenquellen speichern zu können.

Events, Events, Events

Alles, was zur Laufzeit einer CAP-Anwendung passiert, passiert als Reaktion auf Events, die entweder synchron (z. B. eingehende Requests) oder asynchron (z. B. Event Messages) über spezielle Event Handler als Hooks in Service-Providern verarbeitet werden können. Die CAP-Service-Architektur verfolgt mit ihren Prinzipien der losen Kopplung und Kommunikation über klar definierte Schnittstellen und Protokolle ähnliche Ziele wie die hexagonale Architektur. CAP Services unterstützen für diese Kommunikation die Protokolle OData [4], Plain REST/HTTP und AMQP. Mit Hilfe unterschiedlicher Converter können CDS-Service-Provider innerhalb des CAP in APIs basierend auf OData EDMX v2 und v4, JSON Schema, OpenAPI oder AsyncAPI konvertiert werden. Als Laufzeitumgebung für Services bietet CAP Node.js und Java an. Die Beispielanwendung zu diesem Artikel läuft als Spring-Boot-Anwendung mit einem OData-Backend in Java. Ähnlich dem CQRS-Ansatz unterstützt CAP die Separierung von lesenden und schreibenden APIs, indem sie als separate, single-purposed und Use-Case-spezifische Services in Form von Fassaden für unterliegende Domänenmodelle implementiert werden. Aufgrund des Event-getriebenen Ansatzes lässt sich CAP außerdem gut mit Event-Sourcing-Tech...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang