TECH MONDAY: Das C4-Modell in Dynamics 365 und der Power Platform – vier Architekturebenen

Die Architekturdokumentation sollte sowohl die Einbindung des Systems in die Organisation als auch Details zu seinem Aufbau aufzeigen. Das C4-Modell gliedert diese Informationen anhand von vier Abstraktionsebenen.

In Dynamics 365 Customer Engagement- und Power Platform-Projekten lassen sich auf diese Weise Systeme und Integrationen, Dataverse-Lösungen, Anwendungen Power Apps, Microservices, benutzerdefinierte APIs, Workflows und Code beschreiben.

Vier Perspektiven des C4-Modells

Das von Simon Brown entwickelte Modell stellt die Architektur hierarchisch dar – vom allgemeinen Umfeld des Systems bis hin zu den in seinem Code verwendeten Technologien.

Die Bezeichnung „C4“ bezieht sich auf vier Ebenen:

• C1 – Kontext,
• C2 – Container,
• C3 – Komponenten,
• C4 – Code.

Jede weitere Ebene geht auf andere Fragen ein und stellt die Lösung detaillierter dar. Dies erleichtert das Gespräch über Architektur sowohl mit Fachleuten als auch mit Laien ohne technisches Vorwissen.

Einsatz von C4 in Dynamics 365- und Power Platform-Projekten

Die Implementierung von Microsoft-Lösungen umfasst häufig zahlreiche Anwendungen, Dienste und Integrationen. Das C4-Modell ermöglicht es, diese Elemente der entsprechenden Dokumentationsebene zuzuordnen.

Der allgemeine Kontext verdeutlicht die geschäftliche Rolle des Systems und sein Umfeld. Die nachfolgenden Ebenen zeigen die Einheiten, aus denen sich die Lösung zusammensetzt, die für bestimmte Funktionen der Komponente zuständig sind, sowie den verwendeten Code.

Dank dieser Abbildung lässt sich das Modell auch auf Projekte anwenden, bei denen Low-Code- und No-Code-Tools zum Einsatz kommen.

C1 – Systemkontext und dessen Integrationen

Auf der obersten Ebene werden die Zusammenhänge zwischen der Lösung und anderen in der Organisation eingesetzten Systemen dargestellt.

Die Ebene C1 kann die allgemeine logische Architektur von Dynamics 365 Customer Engagement, dessen geschäftliche Rolle sowie die Verbindungen zu folgenden Komponenten veranschaulichen:

• ERP-Systemen,
• Plattformen für das Dokumentenmanagement,
• interne und externe APIs,
• den übrigen in der Organisation eingesetzten Systemen.

Auf dieser Ebene lässt sich nachvollziehen, wo sich die Lösung innerhalb des gesamten Geschäftsumfelds befindet.

C2 – Einheiten zur Speicherung von Logik und Daten

In der C4-Terminologie bezeichnet ein Container eine eigenständig gestartete oder bereitgestellte Einheit, die Geschäftslogik oder Daten enthält.

Es handelt sich weder um einen Docker-Container noch um ein Codemodul oder eine Bibliothek. In der Power Platform-Umgebung können folgende Elemente diese Rolle übernehmen:

• Dataverse-Lösungen,
• Anwendungen Power Apps,
• Mikroservices, die unter Azure laufen und Integrationen oder die Kernlogik des Systems abwickeln.

Die Ebene C2 stellt somit die Hauptkomponenten der Lösung und die Aufteilung der Zuständigkeiten zwischen ihnen dar.

C3 – Komponenten, die bestimmte Funktionen erfüllen

Auf dieser Ebene werden die Elemente dokumentiert, die für eine bestimmte Funktionalität zuständig sind und als Dienst, API-Endpunkt oder Schnittstelle bereitgestellt werden.

Im Power Platform-Ökosystem gehören zu den Komponenten:

• benutzerdefinierte APIs,
• Plug-ins,
• JavaScript-Bibliotheken,
• PCF-Kontrollleuchten.

Unter Berücksichtigung von Low-Code- und No-Code-Tools können dies auch folgende sein:

• Ströme,
• benutzerdefinierte Seiten,
• Canvas-Komponenten.

Auf diese Weise lassen sich sowohl der Code als auch die über die Plattform-Tools konfigurierbaren Elemente mit einer einzigen Dokumentationsmethode erfassen.

C4 – im Code verwendete Technologien

Die detaillierteste Ebene kann Code darstellen, der im Betriebssystem, in einem Cloud-Dienst oder auf einer SaaS-Plattform ausgeführt wird.

In Power Platform-Lösungen können folgende Elemente verwendet werden:

• C#,
• Visual Basic .NET,
• TypeScript oder JavaScript,
• Power Fx.

Zu ihrer Beschreibung kann eine beliebige Notation verwendet werden, beispielsweise UML, Blockdiagramme oder Beziehungsdiagramme.

Praktische Darstellung der Lösungsarchitektur

Für ein Dynamics 365- oder Power Platform-Projekt könnte die Aufteilung wie folgt aussehen:

• Kontext – Geschäftsrolle, Benutzer, Systeme und Integrationen,
• Container – Dataverse-Lösungen, Anwendungen Power Apps und Microservices Azure,
• Komponenten – APIs, Plug-ins, Bibliotheken, Steuerelemente, Workflows und Canvas-Komponenten,
• Programmiersprachen – C#, Visual Basic .NET, TypeScript, JavaScript und Power Fx.

Eine derart strukturierte Dokumentation ermöglicht es, die Architektur auf einer dem Adressaten angepassten Ebene zu erörtern, ohne die Beschreibung ausschließlich auf den traditionell erstellten Code zu beschränken.