DDD trifft Power Platform: Fachlichkeit in Dynamics 365 CE und Dataverse

Teil 6 der Reihe "Software gemeinsam gestalten". Zur Übersicht

In den vorigen Teilen dieser Reihe ging es um Domain-Driven Design als Denkrahmen, Event Storming als Workshop-Format und die gemeinsame Sprache als Fundament. Jetzt wird es konkret: Wie sieht das aus, wenn eure Organisation mit Dynamics 365 CE und der Power Platform arbeitet?

Warum gerade diese Plattform?

Viele Organisationen, gerade im gemeinnützigen Bereich, setzen auf Dynamics 365 Customer Engagement und die Power Platform. Microsoft stellt NPOs vergünstigte oder kostenlose Lizenzen bereit, und das Ökosystem deckt CRM, Fundraising, Projektsteuerung und Kommunikation unter einem Dach ab. Dataverse, die Datenplattform dahinter, bringt ein gemeinsames Datenmodell mit, auf dem alles aufsetzt.

Gleichzeitig bringt die Plattform eigene Annahmen mit, die sich mit DDD-Prinzipien an manchen Stellen reiben. Wer das versteht, kann die Plattform gezielt an die eigene Fachlichkeit anpassen.

Wo sich DDD und Dataverse gut ergänzen

1. 01

   Tabellen als Fachmodell

   Dataverse-Tabellen bilden eure Fachbegriffe ab: Spende, Kontakt, Kampagne, Projekt. Wenn ihr die Tabellen und Spalten so benennt, wie euer Team spricht, entsteht eine Ubiquitous Language direkt in der Plattform. Jede:r erkennt in der Anwendung die eigenen Begriffe wieder.

2. 02

   Model-Driven Apps als Fachsicht

   Dynamics 365 erlaubt mehrere Model-Driven Apps (vorkonfigurierte Anwendungen auf Basis eurer Daten) auf denselben Daten. Das Fundraising-Team sieht einen Kontakt mit Spendenhistorie und Kommunikationsverlauf, die Buchhaltung sieht denselben Datensatz mit Bankverbindung und Buchungssätzen. Verschiedene Sichten auf dasselbe Fundament, genau wie Bounded Contexts verschiedene Perspektiven auf die Domäne abbilden.

3. 03

   Formulare und Ansichten als Kontextgrenzen

   Dataverse erlaubt pro Tabelle mehrere Formulare und Ansichten. So sieht das Fundraising beim Kontakt die Spendenhistorie und Kommunikation, während die Buchhaltung Bankverbindung und Buchungssätze sieht. Die Kontextgrenze verläuft über die Darstellung und die Geschäftsregeln, auch wenn die Daten in derselben Tabelle liegen.

4. 04

   Ereignisse und Automatisierung

   Power Automate und Dataverse-Plug-ins reagieren auf Ereignisse: "Spende eingegangen", "Zuwendungsbestätigung fällig", "Kontakt aktualisiert". Wer im Event Storming die Fachdomäne als Abfolge von Ereignissen visualisiert hat, findet hier einen direkten Weg in die Umsetzung.

Wo es Reibung gibt

Dataverse geht von einem gemeinsamen Datenmodell für die gesamte Organisation aus. Tabellen wie "Kontakt" oder "Firma" sind plattformweit geteilt. Das widerspricht auf den ersten Blick dem Bounded-Context-Gedanken, der für jeden Fachbereich ein eigenes Modell vorsieht.

In der Praxis lösen wir das pragmatisch: Die Kerntabellen bleiben geteilt, aber jeder Fachbereich ergänzt eigene Spalten, Formulare und Ansichten. So sieht das Fundraising-Team bei "Kontakt" andere Felder und Regeln als die Projektverwaltung. Die Grenze verläuft dann über Sichten und Geschäftsregeln, auch wenn die Datenbasis geteilt bleibt.

Benennung ist dabei besonders wichtig. Dataverse zeigt Tabellen- und Spaltennamen direkt in der Oberfläche. Wenn die Plattform "Account" sagt, aber euer Team "Förderer" meint, entstehen genau die Sprachbrüche, die wir im fünften Teil der Reihe beschrieben haben. Nehmt euch die Zeit, Anzeigenamen konsequent an eure Fachsprache anzupassen.

Drei Empfehlungen für den Alltag

1. 01

   Event Storming vor der Konfiguration

   Bevor ihr Tabellen anlegt oder Formulare baut, kartiert den Ablauf gemeinsam an der Wand. Das verhindert, dass die Plattformstruktur den fachlichen Schnitt vorgibt, und sorgt dafür, dass eure Anpassungen einem durchdachten Modell folgen.

2. 02

   Anzeigenamen sind eure Ubiquitous Language

   Tabellen, Spalten und Auswahlfelder in Dataverse tragen die Begriffe, die eure Mitarbeitenden täglich sehen. Investiert früh in saubere, fachlich korrekte Bezeichnungen. Eine spätere Umbenennung ist möglich, aber aufwändiger als eine gute Benennung von Anfang an.

3. 03

   Formulare und Ansichten bewusst schneiden

   Nutzt für jeden Fachbereich eigene Formulare, Ansichten und Dashboards. So sieht jedes Team genau die Felder und Regeln, die zu seiner Arbeit gehören, ohne dass die gemeinsame Datenbasis darunter leidet.

Wie ihr die Werkzeuge der Plattform schneidet und benennt, entscheidet über den Wert für eure Organisation.

Fazit

Dynamics 365 und Dataverse bringen vieles mit, was Domain-Driven Design erleichtert: benennbare Tabellen, mehrere Fachsichten und ereignisbasierte Automatisierung. Die Kunst liegt darin, diese Möglichkeiten bewusst einzusetzen und die Plattform an eure Fachlichkeit anzupassen, mit den Begriffen eures Teams und entlang der Grenzen, die im Event Storming sichtbar geworden sind.