When Business Meets Technology: Vom Datenprodukt zur Datenarchitektur mit Domain-Driven Design

Zusammenfassung

Der Data Product Canvas (DPC) ist ein Werkzeug für die leichtgewichtige und iterative Konzeption von Datenprodukten. Dabei steigert er die Effizienz der Produktdefinition, indem er die wesentlichen Einflussbereiche auf Datenprodukte übersichtlich darstellt und jeweils durch konkrete Fragestellungen Diskussionen über diese Bereich motiviert, an denen Stakeholder*innen aus Management-, Fach- und Entwicklungsabteilungen gleichermaßen teilnehmen können. Aus diesem Grund lässt der DPC jedoch bewusst eine Frage offen: Wie können mit ihm definierte, konzeptionelle Datenprodukte in technische Datenarchitekturen überführt werden? Dieser Artikel stellt ein systematisches Vorgehen für einen essentiellen Schritt vom Datenprodukt zur Datenarchitektur vor. Konkret werden mit Hilfe von Domain-Driven Design (DDD) DPC-Elemente in Domänenmodelle übersetzt. Diese Modelle erfassen die einem Datenprodukt zugrundeliegenden Datenstrukturen ebenso wie die benötigten Schnittstellen zu anderen Systemen und lassen sich anschließend mit etablierten Techniken des DDD in lauffähige Softwaresysteme überführen oder für nachgelagerte Analyse- und Dokumentationszwecke nutzen.

Einleitung

Wer auf LinkedIn und Co. unterwegs ist, muss nicht lange suchen: Erfolgsgeschichten zur Etablierung von Large Language Models, eigenen Machine Learning-Modellen oder datengetriebenen Entscheidungen finden sich wie Sand am Meer. Demgegenüber stehen repräsentative Umfragen wie die des Bitkom aus dem vergangenen Juni, nach der lediglich sechs Prozent der über 600 befragten deutschen Unternehmen überzeugt sind, dass sie ihr durch Daten zur Verfügung stehendes Potenzial ausnutzen. Dementsprechend halten sich auch nur sieben Prozent für Vorreiter bei datengetriebenen Geschäftsmodellen. Warum dies so ist, hat Stephan Hochhaus in seinem Artikel "Mit Applied Data Products zum datengetriebenen Unternehmen" diskutiert und zudem mit dem Data Product Canvas (DPC) ein Werkzeug vorgestellt, das die effektive, leichtgewichtige und iterative Konzeption von Datenprodukten ermöglicht – und das ohne Gefahr zu laufen, sich in technischen Details zu verlieren oder gezwungen zu sein, bereits eine existierende Datenstrategie für das gesamte Unternehmen entwickelt zu haben.

Während der DPC ein Werkzeug ist, mit dem bei geringer Einstiegshürde und Ressourcenaufwand Datenprodukte durch die Kollaboration verschiedener Stakeholder*innen aus Management, Fach- und Technikabteilungen in kurzer Zeit definiert werden können, lässt er bewusst eine Frage offen: Wie können beschriebene konzeptionelle Datenprodukte in technische Datenarchitekturen unter Berücksichtigung bestehender Systemlandschaften überführt werden? Dieser Artikel stellt ein systematisches Vorgehen für einen essentiellen Schritt vom Datenprodukt zur Datenarchitektur vor, das DPC-Elemente in Domänenmodelle übersetzt. Diese Modelle erfassen die einem Datenprodukt zugrundeliegenden Datenstrukturen ebenso wie die benötigten Schnittstellen zu anderen Systemen. Für ihre Erstellung kommt dabei Domain-Driven Design (DDD) zum Einsatz und damit eine Methodik, die viele Gemeinsamkeiten mit dem DPC aufweist, etwa den Fokus auf Kollaboration zwischen Business und Technik, eine geringe Einstiegshürde, wenn man sich auf ausgewählte Modellierungselemente beschränkt, sowie eine visuelle Darstellung von Ergebnissen. Im Gegensatz zum DPC antizipiert DDD jedoch die technische Verfeinerung von Domänenmodellen, die bei hinreichendem Detailgrad dann als Blaupause für das Softwaredesign bzw., mit einem DPC als Ausgangspunkt, dem domänengetriebenen Design von Datenarchitekturen dienen können. Ein weiterer Vorteil DDD ist die Verfügbarkeit einer etablierten Wissensbasis über die Nutzbarkeit von Domänenmodellen, bspw. für die Ableitung von Schnittstellen, das Design eventgetriebener Softwarearchitekturen oder als Grundlage für die Steigerung der Wartbarkeit von Softwaresystemen.

Der Artikel beginnt mit einer kurzen Vorstellung des benötigten Hintergrundwissens über DDD, illustriert dann die Transformation von DPCs in DDD-basierte Domänenmodelle anhand der Retail-Domäne und ihres Use Cases “Sortiments-Benchmarking”, gibt einen zusammenfassenden Überblick der Transformationsschritte in wiederverwendbarer Form und schließt mit einem Ausblick ab.

Hintergrund: Domain-Driven Design

DDD geht auf das 2003 erschienene, gleichnamige Buch von Eric Evans zurück. Kern der DDD-Methodik ist die Zusammenarbeit von Fachexpert*innen und Stakeholder*innen mit technischem Hintergrund, wie bspw. Softwareentwickler*innen oder -architekt*innen. Durch diese Zusammenarbeit kann ein tieferes Verständnis der Konzepte und Prozesse einer Geschäftsdomäne zwecks ihrer Realisierung in Software erlangt werden. Dies gelingt durch die Erfassung von Geschäftskonzepten und -prozessen in Domänenmodellen, die zunächst eine Diskussion auf fachlicher Ebene ermöglichen, sich aber durch bestimmte Muster des DDD auch in technologischer Hinsicht verfeinern lassen. Die nachgelagerte Implementierung hinreichend verfeinerter Domänenmodelle führt nach DDD dann zu einer Software, die Fachkonzepte und -prozesse ganzheitlich, d.h. von ihrer Oberfläche über ihre interne Struktur bis hin zum Quellcode, abbildet und somit den fachlichen Anforderungen besser entspricht als ohne die Anwendung von DDD.

Evans untergliedert DDD in zwei Designphasen, Strategic Design und Tactical Design, die die beiden folgenden Abschnitte in dem Maße darstellen, wie für das weitere Verständnis des Artikels benötigt.

Strategic Design

Ziel des Strategic Designs ist, dem Teile-und-Herrsche-Gedanken folgend, die Zerlegung bzw. Dekomposition eines bestehenden oder zu entwickelnden komplexen Softwaresystems in kleinere, besser handhabbare Einheiten. Dazu definiert DDD das Bounded Context-Muster: Ein Bounded Context macht die Grenzen der Gültigkeit und Anwendbarkeit eines Domänenmodells und seiner Elemente explizit. Somit kann es sich bei einem Bounded Context z. B. um eine Organisationseinheit in einem Unternehmen, ein anderes System oder ein Modul eines Gesamtsystems handeln. Typische Beispiele für Bounded Contexts in E-Commerce-Systemen umfassen etwa die Rechnungsstellung, der Warenkorb und die Kundenverwaltung.

Die Beschränkung der Gültigkeit und Anwendbarkeit eines Domänenmodells auf einen Bounded Context führt dazu, dass ein Bounded Context immer eine eigene domänenspezifische Sprache, die sog. Ubiquitous Language modelliert. Dies hat neben einer zielgerichteteren Kommunikation zwischen Fachexpert*innen und technischen Stakeholder*innen u. a. auch den Vorteil, dass die Bedeutung gleichnamiger Domänenkonzepte in verschiedenen Kontexten eindeutig zu definieren ist. So begreift die Rechnungserstellung das Konzept “Kund*in” etwa als unveränderliche Information, die den Namen und die Rechnungsadresse von Kund*innen umfasst, wohingegen die Kundenverwaltung nicht über Lieferadressen von Kund*innen spricht, sondern auch an deren Zufriedenheit mit den Produkten des Unternehmens interessiert ist.

Damit komplexe Softwaresysteme ihre Funktionalität bei guter Wartbarkeit erfüllen können, müssen verschiedene Systemteile zusammenarbeiten. So kommt es im Kontext von E-Commerce-Systemen typischerweise dazu, dass ausgehend vom Warenkorb nach Abschluss eines Kaufvorgangs durch eine Kund*in eine Rechnung zu generieren ist. An dem beschriebenen Prozess wären dann etwa die Bounded Contexts “Rechnungserstellung” und “Warenkorb” beteiligt. Für den Zweck der Kollaboration eines Bounded Contexts mit einem anderen sieht DDD explizit die Modellierung von Beziehungen zwischen Bounded Contexts vor. Bei konsequenter Anwendung von DDD können Informationen zwischen Bounded Contexts oder ihrer späteren Realisierung in Form von Softwaremodulen ausschließlich auf Basis dieser Beziehungen stattfinden. In diesem Sinne erlauben die Beziehungen explizit den Austausch von Domänenkonzepten, bspw. von Warenkorbinhalt mit Rechnungsersteller, oder die Nutzung zugehöriger Funktionalitäten, bspw. die Zuordnung anonymer Warenkörbe zu Kund*innen, die bei der Warenkorberstellung noch nicht am System angemeldet waren. In Abhängigkeit des Umfangs einer Bounded Context-Beziehung kennt DDD sieben Typen solcher Beziehungen bzw. Interaktionsmuster. Für das weitere Verständnis des Artikels sind jedoch nur die folgenden drei von Relevanz:

• Customer/Supplier: Dieses Interaktionsmuster betrachtet einen der verbundenen Bounded Contexts als Customer und den anderen als Supplier. Der Customer ist abhängig von einem Teil der Domänenkonzepte oder Funktionalitäten des Suppliers. Das Interaktionsmuster ermöglicht die Abbildung dieser Beziehung und hilft dabei, bestehende Anforderungen des Customers an den Supplier sichtbar zu machen. Ob und wann der Supplier diese Anforderungen erfüllt, ist durch das Muster jedoch nicht vorgegeben und kann von vielen Faktoren abhängig sein, bspw. vom Gesamtsystem, bestehenden Team- und Kommunikationsstrukturen oder auch den Anforderungen und ihrer Priorisierung.
• Anticorruption Layer (ACL): Analog zum Customer/Supplier-Muster adressiert auch das ACL-Muster Situationen, in denen ein Bounded Context von den Konzepten eines anderen abhängig ist, wobei ein ACL eine Übersetzungsschicht am abhängigen Bounded Context modelliert. Dies bedeutet, dass der abhängige Bounded Context vollumfänglich für die Integration der Konzepte des unabhängigen Bounded Contexts in sein eigenes Domänenmodell verantwortlich zeichnet. Im Gegensatz zum Customer/Supplier-Muster ist die Kopplung der Bounded Contexts also dahingehend geringer, dass der unabhängige Bounded Context die Anforderungen des abhängigen Bounded Contexts ignoriert. Letzterer muss sie im Rahmen der Implementierung des ACLs selbst bedienen.
• Open Host Service (OHS): Im Rahmen eines OHS spezifiziert ein Bounded Context ein Kommunikationsprotokoll für die Nutzung eines Teils seiner Domänenkonzepte und Funktionalitäten und macht dieses Protokoll öffentlich verfügbar, sodass es von anderen abhängigen Bounded Contexts für die Interaktion mit dem unabhängigen Bounded Context genutzt werden kann. Oftmals werden OHSs durch Modulschnittstellen realisiert. Das OHS-Muster impliziert eine Kopplung zwischen zwei Bounded Contexts, die über das Maß der Kopplung einer Customer/Supplier-Beziehung hinausgeht: Abhängige Bounded Contexts nutzen die vom unabhängigen Bounded Context bereitgestellte Schnittstelle in der angebotenen Form. Anforderungen einzelner abhängiger Bounded Contexts werden i. d. R. nicht berücksichtigt.

Durch die Modellierung von Interaktionsmustern zwischen Bounded Contexts ergibt sich eine zusammenhängende Context Map, die Auskunft über konzeptionelle und technische Abhängigkeiten zwischen verschiedenen Systemmodulen gibt. Da DDD die Verantwortung für einen Bounded Context immer bei exakt einem Team sieht, zeigen Context Maps auch immer Team-Beziehungen und -kommunikationsstrukturen auf.

Tactical Design

Beim Tactical Design fokussiert DDD die Ausgestaltung des Domänenmodells eines Bounded Contexts, d. h. die Modellierung seiner Domänenkonzepte und zugehörigen Funktionalitäten. Analog zum Strategic Design spezifiziert DDD auch für diese Designphase gewisse Muster, mit denen sich die Semantik von Modellelementen bestimmen lässt und die z. T. schon gewisse Entscheidungen für die technische Implementierung der Modellelemente vorwegnehmen.

Im Weiteren sind die folgenden Muster des Tactical Designs relevant:

• Entity: Entities sind Domänenkonzepte, deren Instanzen eindeutig voneinander unterscheidbar sein müssen. Eine Entity definiert in diesem Sinne eine domänenbezogene Identitätsbedingung. Beispielsweise erlaubt das Domänenkonzept “Bestellung” eines E-Commerce-Systems auf Basis einer “Bestellnummer” die eindeutige Unterscheidung zweier Bestellungen. In der Regel sind Eigenschaften von Domänenkonzepten, die zwei Konzeptinstanzen unterscheidbar machen, unveränderbar. Alle weiteren Eigenschaften bestimmen den Zustand einer Konzeptinstanz und lassen sich auch nach Erstellung der Instanz bis zu einem gewissen Zeitpunkt anpassen. So bleibt die Bestellnummer einer Bestellung oftmals gleich, wohingegen Informationen wie Versandstatus oder Lieferaktualisierungen derselben mehreren Änderungen unterliegen können.
• Aggregate: Aggregates sind Domänenkonzepte, die andere Konzepte bündeln, sowie Gültigkeitskriterien und einen Lebenszyklus über diese Konzepte definieren. In diesem Sinne ermöglicht ein Aggregate die Behandlung einer Menge von Domänenkonzepten als Einheit. Im Kontext des E-Commerce-Systems lässt sich das Konzept “Kund*in” als Aggregate modellieren, welches Bestellungen und Adressen kapselt. Das Aggregate könnte dann festlegen, dass Kund*innen nur dann gültig sind, wenn sie jeweils mindestens eine Liefer- und eine Rechnungsadresse besitzen.
• Service: Services dienen der Modellierung von Geschäftslogik, die sich nicht eindeutig einer Entity oder einem Aggregate zuordnen lässt. Bei einem E-Commerce-System wäre etwa der “Versand-Service” zur Berechnung der Versandkosten einer Bestellung unter Berücksichtigung von Kund*inneneigenschaften, z. B. Entfernung zum Lieferort oder Teilnahme am Bonusprogramm, ein Service gemäß DDD.
• Repository: Repositories modellieren Schnittstellen zur Datenhaltung von Entities oder Aggregates. Diese Schnittstellen sehen i. d. R. Funktionalitäten für das Speichern, Auslesen und Löschen von Instanzen von Domänenkonzepten vor und deuten darauf hin, dass bei der technischen Implementierung eine Datenbankanbindung benötigt wird.

Vom Data Product Canvas zum Domänenmodell

Dieser Abschnitt erläutert die schrittweise Transformation eines DPC in ein DDD-basiertes Domänenmodell. Ausgangspunkt bildet das Strategic Design, in dessen Rahmen Bounded Contexts identifiziert und ihre Beziehungen klassifiziert werden, sodass eine Context Map entsteht. Im nächsten Schritt wird die Context Map dem Tactical Design folgend verfeinert, wobei der Bounded Context des betrachteten Datenprodukts im Vordergrund steht. Das ist dann ein Domänenmodell des Datenprodukts, aus dem sich nachgelagert ein Softwaredesign für die Produktimplementierung ableiten lässt.

Das Beispiel-Datenprodukt “Sortiments-Benchmarking”

Um den Übergang von DPCs zu DDD-basierten Domänenmodellen zu illustrieren, greift der Artikel auf ein Beispiel-Datenprodukt aus der Domäne “Handel” bzw. “Retail” zurück: Das Datenprodukt “Sortiments-Benchmarking” soll es Unternehmen erlauben, ausgehend von angebotenen Produkten, ihrer Kategorien und weiteren Eigenschaften, wie bspw. Preis oder Qualität, die eigene Marktposition im Vergleich zu Wettbewerbern zu bestimmen.

Die folgende Abbildung zeigt den DPC des Beispiel-Datenprodukts.

Das Beispiel-Datenprodukt “Sortiments-Benchmarking” setzt unterschiedliche Data Provider ein, die automatisiert Daten über konkurrierende Handelsprodukte aus Online-Katalogen von Wettbewerbern extrahieren (Web-Crawler) oder Erkenntnisse aus Vorortbesuchen anderer Märkte durch Mystery Shopper bereitstellen (On-Site Datenerhebung). Die so zur Verfügung stehenden Daten werden mittels spezialisierter Data Processing-Schritte verarbeitet, um etwa Konflikte bei der Kategorisierung von Produkten zu lösen oder Produktsortimente manuell pflegen zu können. Die Frequency, in der Eingangsdaten aktualisiert werden, variiert in Abhängigkeit vom Data Provider zwischen Tages- und Wochenzyklen. Als Storage von Eingangs- und erzeugten Daten dient sowohl ein Lakehouse wie auch eine dedizierte Data Platform. Die größte Zahl der Anwendungsszenarien der adressierten Target User wird durch diese Plattform umgesetzt. Analyst*innen können Produktportfolios von Wettbewerbern über standardisierte Reports als Self-Service der Data Platform abfragen und dann näher untersuchen. Weiterhin bietet das Datenprodukt eine Schnittstelle für die Sortimentszuordnung von Produkten durch Category Manager*innen an, während Einkäufer*innen für strategische Entscheidungen auf unternehmensspezifische Reports zurückgreifen.

Identifikation von Bounded Contexts

Am Beginn der Transformation des Beispiel-DPC zum “Sortiments-Benchmarking” in ein DDD-basiertes Domänenmodell steht die Identifikation von Bounded Contexts aus dem DPC mittels Strategic Design. Hierbei werden explizit auch Bounded Contexts berücksichtigt, die nicht direkt Teil des Datenprodukts sind, sondern etwa externe Systeme beschreiben.

Die folgende Abbildung zeigt die aus dem Beispiel-DPC identifizierten Bounded Contexts. Abgerundete Rechtecke mit dem Stereotyp <<Context>> repräsentieren Bounded Contexts und graue Rechtecke mit gestrichelten Linien geben dasjenige DPC-Feld an, aus dem die im Rechteck gezeigten Bounded Contexts hervorgehen.

Jeder Data Provider des Beispiel-DPC wurde auf einen eigenen Bounded Context abgebildet, da jeder Provider ein System, bspw. einen “Web-Crawler”, oder eine Organisationseinheit, bspw. ein Dienstleistungsunternehmen für die “On-Site Datenerhebung”, darstellt. Data Provider sind in diesem Sinne also produktexterne Komponenten, von denen das Datenprodukt abhängt. Hierzu zählt auch der unternehmenseigene “Produktdatenkatalog”, da für den Beispiel-DPC angenommen wird, dass dieser durch ein dediziertes Team entwickelt, gewartet und bereitgestellt wird. Je nach Arbeitsumfeld könnte er jedoch auch Teil des Bounded Contexts des Datenprodukts sein, wenn z. B. die Pflege von Produktdaten auch im Verantwortungsbereich des Sortiments-Benchmarkings liegt. Hier zeigt sich eine Stärke DDD-basierter Domänenmodelle: Sie machen Wissen um konzipierte oder bereits existierende organisatorische oder technische Zusammenhänge explizit und ermöglichen so durch eine vglw. hohe Abstraktionsebene zielgerichtete Diskussionen um die Sinnhaftigkeit dieser Zusammenhänge und ihrer Grenzen zueinander.

Das eigentliche Datenprodukt “Sortiments-Benchmarking” wird durch den gleichnamigen Bounded Context beschrieben. Diese Eins-zu-eins-Abbildung von Datenprodukten auf Bounded Contexts macht zunächst für jeden DPC Sinn, da das erfasste Datenprodukt ein neues oder bestehendes System darstellt, das mit anderen Komponenten interagiert. Sollte diese Abbildung jedoch für einen konkreten DPC diskutabel erscheinen, könnte dies auf eine zu starke Kopplung mit anderen Komponenten hindeuten. Eine solche Erkenntnis geht i. d. R. aus der Modellierung bestehender Systemlandschaften mit DDD hervor und unterstreicht wiederum die Stärke von DDD als Analysewerkzeug. Andererseits zeigt sich auch hier die Kompatibilität von DPC und DDD, da sich der DPC ebenfalls für die Realisierung neuer wie auch für die Erfassung und Untersuchung bestehender Datenprodukte problemlos einsetzen lässt.

Analog zum Datenprodukt ist auch die “eigene Data Platform mit Self-Service” aus dem Storage-Feld des Beispiel-DPC in einem eigenen Bounded Context gekapselt. Sie fungiert als eigenständiges System, das den Target Users anwendungsspezifisch Zugriff auf das Datenprodukt gewährt. Oftmals sind Datenprodukte jedoch direkt in Datenplattformen integriert, da ausschließlich die Plattform als Produkt verstanden wird, nicht aber die Daten. Das DPC kann durch seinen inhärenten Fokus auf Datenprodukte derlei starke Kopplungen aufzeigen und durch die Übertragung in DDD-basierte Domänenmodelle auch zu ihrer Auflösung beitragen, wenn ein entsprechender Bounded Context dahingehend aufgelöst wird, dass Plattform- und Datenkonzepte in neuen, spezialisierten Bounded Contexts modelliert werden. Die Trennung dieser Konzepte ist Voraussetzung für das Verständnis von Daten als Produkte, da Datenprodukte i. d. R. anderen Entwicklungsansätzen, Lebenszyklen und Qualitätsanforderungen als Software-Plattformen unterliegen.

Jede Art von Target Users im Beispiel-DPC wird auf einen Bounded Context abgebildet, da die adressierten Anwender*innen des Sortiments-Benchmarkings im Unternehmen unterschiedlichen Abteilungen oder Teams zugeordnet sind. Die Heterogenität ihrer Anforderungen wird somit bereits im Domänenmodell deutlich, wenn etwa die Beziehungen zwischen den Bounded Contexts der Target Users und dem des Datenprodukts jeweils verschiedenartig klassifiziert werden.

Modellierung und Klassifikation von Context-Beziehungen

Dieser Schritt modelliert und klassifiziert Beziehungen zwischen den Bounded Contexts des Beispiel-DPC. Er führt zu der folgenden Context Map, in der graue Rechtecke mit gestrichelten Linien die Semantik von zwei oder mehr Beziehungen zwischen denselben Bounded Contexts angeben.

Die Data Provider-bezogenen Bounded Contexts “Web-Crawler je Wettbewerber” und “Third Party Data Provider” sind über einen ACL mit dem Data Product-Bounded Context “Sortiments-Benchmarking” verbunden. Diese vergleichsweise schwache Beziehung zeigt an, dass das Datenprodukt für die Integration der von den beiden externen Komponenten gelieferten Daten in das eigene Domänenmodell selbst verantwortlich ist. Die beiden externen Komponenten nehmen in diesem Sinne keine Rücksicht auf die Anforderungen des Datenprodukts. Für dessen Team bedeutet diese Beziehung allerdings eine erhöhte Verantwortung und zusätzlichen Aufwand, da der ACL für die Transformation der externen Daten konzipiert, implementiert und angepasst werden muss, wenn sich die Domänenmodelle und damit die Datenstrukturen der externen Komponenten ändern. Dank der Context Map lässt sich dieser Umstand frühzeitig erkennen und entsprechend einplanen.

Für die Integration der Data Provider-Bounded Contexts “On-Site Datenerhebung” und “Werbeprospekte” bietet der Data Product-Bounded Context jeweils einen OHS an. Oftmals werden OHSs als synchrone Schnittstellen auf HTTP-Basis implementiert. Eine OHS-Beziehung modelliert eine starke Kopplung zweier Bounded Contexts, da einerseits der den OHS anbietende Bounded Context (hier “Sortiments-Benchmarking”) die Schnittstelle implementieren und warten muss und der den OHS nutzende Bounded Context (hier “On-Site Datenerhebung” und “Werbeprospekte”) die Anforderungen der Schnittstelle hinsichtlich Syntax und Semantik kontinuierlich berücksichtigen muss, um einen korrekten Datenaustausch zu gewährleisten. Die Teams der so verbundenen Bounded Contexts müssen also aktiv kommunizieren, um Anforderungen und resultierende Umsetzungsentscheidungen den OHS betreffend abzustimmen. Im Kontext des Beispiel-DPC ist diese Art der Beziehung einerseits notwendig, da die Mystery Shopper ihre Erkenntnisse der On-Site Datenerhebung über eine dedizierte Schnittstelle an das Datenprodukt übermitteln, sodass sie umgehend für Auswertungen zur Verfügung stehen. Andererseits ermöglicht der OHS für den Bounded Contexts “Werbeprospekte” Mitarbeitenden des Unternehmens, welches das Datenprodukt verwendet, den Upload von Werbematerialien konkurrierender Unternehmen für nachgelagerte Analysen.

Das Datenprodukt bezieht außerdem den “eigenen Produktdatenkatalog” des Unternehmens mit ein, wobei im Vergleich zum vorangegangenen Absatz der OHS durch den entsprechenden Data Provider-Bounded Context und nicht den Data Product-Bounded Context angeboten wird. Hintergrund dieser Modellierung ist die Tatsache, dass der Produktdatenkatalog durch ein Softwaresystem realisiert wird, welches durch das Unternehmen eingekauft wurde. Während der Katalog durch ein unternehmenseigenes Team gepflegt wird, liegt die Entwicklung und der Betrieb des zugrundeliegenden Softwaresystems jedoch bei einem externen Dienstleister. Dieser bietet eine Schnittstelle für Abfragen katalogisierter Produktdaten an, sodass das Datenprodukt sie automatisiert verarbeiten kann.

Das Datenprodukt nutzt für die Speicherung die unternehmenseigene Data Platform mit Self-Service. Die Context Map bildet diese Abhängigkeit durch die Customer/Supplier-Beziehung (C/S-Beziehung) zwischen den Contexts “Eigene Data Platform mit Self-Service” und “Sortiments-Benchmarking” ab. Sie zeigt damit an, dass der Data Product-Bounded Context Domänenkonzepte und Daten bereitstellt, die vom Storage-Bounded Context benötigt werden, wobei letzterer gewisse Anforderungen an die Bereitstellung der Konzepte und Daten stellt. Sie macht allerdings noch keine Aussagen über die konkrete Realisierung des Datenaustauschs. Beispielsweise würde sich im Falle des Beispielprodukts ein kontinuierliches Streaming von Daten anbieten, um Analysen auf Basis einer möglichst aktuellen Datenlage durchführen zu können. Dieser Umsetzungsaspekt ist jedoch noch genauer zwischen Datenprodukt- und Plattform-Team zu diskutieren, da er vglw. hohe technische Anforderungen, v. a. an die Skalierbarkeit, Verarbeitungsgeschwindigkeit und Fehlertoleranz der Data Platform stellt, die durch das Datenprodukt-Team als Supplier der C/S-Beziehung sinnvollerweise berücksichtigt werden sollten.

An dieser Stelle zeigt sich auch, dass DPCs und abgeleitete DDD-basierte Domänenmodelle nicht alle notwendigen Informationen zur Umsetzung eines Datenprodukts erfassen. Vielmehr ermöglichen beide Modellarten eine schnelle Dokumentation und Übersicht gewisser Erkenntnisse über das Produkt und die Zusammenhänge zwischen seiner geschäftlichen Bedeutung und seinem Softwaredesign. Durch den hohen Abstraktionsgrad sind DPCs und Domänenmodelle zudem sehr gut für Diskussionen zwischen verschiedenen Stakeholder*innen im Hinblick auf die Produktumsetzung geeignet. Relevante Zusatzinformationen, z. B. zur Organisationsstruktur von Unternehmen, der existierenden Systemumgebung, in die das Datenprodukt eingebettet werden muss, oder der genauen Bedeutung von Domänenkonzepten, sollten jedoch in separaten Artefakten wie Organigrammen, Architekturdokumentationen oder Glossaren festgehalten werden.

Für die Target Users-Bounded Contexts “Analytics”, “Category Management” und “Purchasing” stellt der Data Product-Bounded Context “Sortiments-Benchmarking” zwei gesonderte OHSs bereit. Der erste unterstützt das “Category Management”-Team beim Export von Metadaten über die vom Datenprodukt bereitgestellten Daten. Zu diesen Metadaten zählen bspw. Feldnamen, -typen und -relationen oder die Herkunft, Aktualität und Abfrageintervalle von Daten. Ferner bietet ein zweiter OHS den Teams “Category Management” und “Purchasing” eine Schnittstelle für die manuelle Zuordnung unternehmenseigener Produkte zu Sortimenten und damit verbunden auch die Behebung von Konflikten. Alle Target Users-Bounded Contexts stehen jeweils mit der Data Platform in einer C/S-Beziehung, welche die Self-Service-Funktionalität der Plattform abbildet: Target Users haben über die Plattform die Möglichkeit, Daten für ihre Analysen abzufragen. Darunter fällt insbesondere auch die Interaktion von Mitarbeitenden mit dem Datenprodukt selbst.

Domänenmodellierung des Datenprodukts

Auf Basis der Context Map kann nun im Rahmen des Tactical Design das Domänenmodell des Datenprodukts erstellt werden. Seine konkrete Ausgestaltung ergibt sich dabei u. a. aus den Beziehungen des Bounded Contexts des Datenprodukts “Sortiments-Benchmarking”. Des Weiteren nimmt das Modell auch die zum aktuellen Zeitpunkt bereits bekannten Domänenkonzepte, etwa für die Datenspeicherung oder -strukturierung, mit auf. Mit Hilfe spezieller Muster kann die Semantik dieser Konzepte spezifiziert werden, wodurch z. T. auch schon gewisse Entscheidungen für die spätere Überführung des Domänenmodells in eine lauffähige Implementierung vorweggenommen werden. Neben der Context Map ist das Domänenmodell das zentrale Artefakt bei der Anwendung von DDD auf DPCs. Es stellt ein leichtgewichtiges Dokumentations- und Kommunikationsmedium zwischen fachlicher und technischer Perspektive auf ein Datenprodukt dar.

Die nachstehende Grafik zeigt das Domänenmodell des Data Product-Bounded Contexts nach durchgeführtem Tactical Design.

Das Domänenmodell integriert je einen Service für jeden über einen ACL oder OHS mit dem Bounded Context in Verbindung stehenden Data Provider-Bounded Context. Die Konverter-Services “HTML-Sortimentsdatensatz (SD)-Konverter” und “Third-Party-SD-Konverter” überführen abgegriffene HTML-Seiten von Wettbewerbern und von spezialisierten Dienstleistern bereitgestellte Marktdaten in das Domänenmodell des Datenprodukts. Die Services “Regalfoto-Analyse” und “PDF-Analyse” implementieren analoge Funktionen, mit denen sich über die Schnittstellen für die On-Site Datenerhebung und die Einstellung von Werbeprospekten übermittelte Daten für das Produkt aufbereiten lassen. Der “SAP Connector”-Service übernimmt die regelmäßige Abfrage und Aufbereitung des eigenen Produktdatenkatalogs.

Das Domänenmodell des Datenprodukts ist durch die modellierten Aggregates und Entities definiert, wobei zwischen Datenstrukturen für die Harmonisierung eingehender Daten (produktinterner Fokus) und Datenstrukturen für die Benutzung des Produkts durch andere Komponenten (produktexterner Fokus) unterschieden wird. Das Aggregate “Sortimentsdatensatz” stellt das zentrale Domänenkonzept für den produktinternen Fokus dar. Es kapselt Datenstrukturen, mit denen sich Produktsortimente abbilden lassen. Die Entity “Metadaten” speichert Informationen, die einen Produktdatensatz beschreiben, bspw. wann dieser erstellt oder zuletzt aktualisiert wurde, oder auch, ob er das eigene Sortiment oder das eines Wettbewerbers beschreibt. Demnach spielt dieses Domänenkonzept die Schlüsselrolle für das Benchmarking des unternehmenseigenen mit konkurrierenden Sortimenten. Die Entity “Positionsdaten” nimmt die eigentlichen Daten von Sortimentsprodukten auf.

Alle bereits beschriebenen Services müssen Daten in das “Sortimentsdatensatz”-Aggregate überführen. Diese Information geht, wie auch die Felder der Entities, noch nicht aus dem gezeigten Domänenmodell hervor. Mit DDD kann das Modell jedoch entsprechend ergänzt werden, indem etwa Services Methodensignaturen hinzugefügt werden, anhand derer sich erkennen lässt, welche Domänenkonzepte sie nutzen, oder indem Entities mit Attributen erweitert werden, die Entity-Felder modellieren. Für Domänenmodelle, an deren Erstellung Stakeholder*innen mit unterschiedlichem Wissensstand über DDD beteiligt sind, kann es zunächst jedoch sinnvoll sein, Strukturen von Domänenkonzepten in einem separaten Glossar in natürlicher Sprache festzuhalten und erst mit steigender Sicherheit in der Anwendung von DDD in die erstellten Modelle zu integrieren.

Das Repository “Sortimentsdaten” repräsentiert den Speicher für das Aggregate “Sortimentsdatensatz” und zeigt somit an, dass das Datenprodukt Instanzen des Aggregates langfristig vorhält.

Die Entity “Produktkategorisierung” und das Repository “Kategorisierte Produkte” dienen der Anreicherung des Datenprodukts um Produktkategorien, auf deren Basis letzten Endes Sortiments-Benchmarkings durchgeführt werden. Der Service “Kategoriematcher” fasst Produkte zu Kategorien, bspw. Bekleidung, Haushaltskleingeräte oder Süßigkeiten, zusammen, wobei das Domänenmodell keine Auskunft darüber gibt, wie das Matching realisiert wird. Denkbar wäre hier etwa der Einsatz eines speziell trainierten Machine Learning Models. Zusätzlich könnte der Service den Teams “Category Management” und “Purchasing” die Möglichkeit geben, Matchings manuell hinzuzufügen oder nachträglich anzupassen, etwa unter Zuhilfenahme des “Konfliktbeheber”-Services, der Matching-Konflikte aufzeigt und Vorschläge für ihre Lösung anbietet.

Schlussendlich kann das “Category Management”-Team den “Metadaten-Exporter”-Service nutzen, um Metadaten über das Datenprodukt abzufragen.

Überblick der Transformationsschritte von Data Product Canvases zu Domänenmodellen

Die folgende Liste gibt, ausgehend vom vorangegangenen Beispiel, einen kondensierten Überblick über die Schritte der Überführung von DPCs in DDD-basierte Domänenmodelle, wobei DDD-Grundlagen, etwa die Muster des Strategic Design und Tactical Design, aus Gründen der Übersichtlichkeit bewusst ausgespart werden. Die allgemeine Formulierung der Schritte ermöglicht die Anwendung auf andere DPCs als zum “Sortiments-Benchmarking”.

• Allgemeine Schrittfolge:
  • Strategic Design: Identifikation von Bounded Contexts
  • Strategic Design: Erstellung Context Map durch Modellierung und Klassifikation von Context-Beziehungen
  • Tactical Design: Erstellung des Domänenmodells des Datenprodukts
• Identifikation von Bounded Contexts:
  • Ein Bounded Context für das Datenprodukt mit der Möglichkeit späterer Verfeinerung gemäß iterativem DDD
  • Je ein Bounded Context für jedes externe System
  • Je ein Bounded Context für jeden Data Provider
  • Je ein Bounded Context für jeden Storage, der nicht in das Datenprodukt integriert werden soll oder kann, bspw. generische Datenplattformen mit Self-Service
  • Je ein Bounded Context für jede Target Users-Art
• Erstellung Context Map:
  • Beziehungen anhand der Stärke der Kopplung zwischen Bounded Contexts modellieren
  • ACL, wenn Datenprodukt externe Daten in eigene Strukturen überführen muss
  • OHS, wenn Personen oder Systeme den Datenaustausch mit dem Datenprodukt selbst initiieren
  • C/S, wenn konkrete Ausgestaltung des Datenaustauschs noch nicht klar jedoch bekannt ist, ob das Datenprodukt oder das andere System die Anforderungen an den Austausch vorgibt
• Erstellung des Domänenmodells des Datenprodukts:
  • Je ein Service für jeden ACL oder OHS des Datenprodukts
  • Unterscheidung zwischen Datenstrukturen für die Harmonisierung eingehender Daten (produktinterner Fokus) und Datenstrukturen für die Benutzung des Produkts durch andere Komponenten (produktexterner Fokus)
  • Zusatzinformationen wie Strukturen von Domänenkonzepten oder ihre Nutzung durch Services zunächst in separaten Artefakten (bspw. Glossaren) festhalten und ggf. später in Domänenmodelle integrieren

Zusammenfassung und Ausblick

In diesem Artikel wurde ein systematisches Vorgehen für die Überführung von Data Product Canvases (DPCs) in Domänenmodelle als wesentliche Vorstufe technischer Datenarchitekturen vorgestellt. Unter Rückgriff auf die beiden Phasen Strategic Design und Tactical Design des Domain-Driven Design (DDD) sowie die zugehörigen Muster können DPC- auf DDD-Elemente abgebildet werden. Hierdurch ergeben sich Erkenntnisse, die für die Implementierung des Datenprodukts essentiell sind, wie bspw. eine Zerlegung des Produkts in spezialisierte Module nach dem Teile-und-Herrsche-Prinzip, die Abhängigkeitsstruktur dieser Module, Kommunikationsbeziehungen und Verantwortlichkeiten von Teams sowie eine kostengünstige Blaupause für das Softwaredesign, welche sich iterativ mit etablierten Techniken des DDD anpassen lässt.