Ereignisorientierung im App-Ökosystem – Architekturdetails als Garant für erfolgreiche Integration

Ereignisorientierung ist in vielen Aspekten für IoT-Systeme geeignet, weil reale Ereignisse verarbeitet werden. Die passende Architektur und Implementierung ist aber alles andere als offensichtlich und erfordert, dass sich Architekten und Entwickler gemeinsam um viele Details kümmern. Wir zeigen Lösungen für ein skalierbares und erweiterbares App-Ökosystem mit Logistikfokus: Error Handling, Schnittstellen, Daten- und Eventmodellierung mit Generierung von Entwickler-spezifischen Sichten, Einfluss auf die Clients und Umsetzung in AWS mit Reactor.

Zielpublikum: Architekten, Entwickler, Projektleiter
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
- Wir berichten aus der Entwicklung eines Produktivsystems: App-Ökosystem aus der Logistik-Domäne
- Logistik ist eine Domäne, in der sehr viele diskrete Ereignisse wie Paketübergaben passieren. Deshalb erscheint Ereignisorientierung als geeigneter Architekturstil
- Logistik ist auch eine Domäne, in der (schon länger) das IoT Einzug hält: z.B. durch Erkennung von Paketen, Ausstattung von Containern mit Sensorik, intelligenten Packstationen, …
- Wir hatten insbesondere Anforderungen aus dem Bereich Erweiterbarkeit der fachlichen Abläufe und schnelle Änderbarkeit: Ausprobieren von Geschäftsmodellen, neuen Funktionen, Interaktionskonzepte, …
- Wie Ereignisorientierte Architekturen im Detail aussehen sollten, lässt Architekten und Entwicklern großen Spielraum. Es gibt diverse Patterns und Frameworks, dennoch muss sehr viel konzipiert werden und vor allem sehr einheitlich über das System hinweg umgesetzt werden
- Wir zeigen unsere konkreten Lösungen rund um Event-Orientierung: Error Handling, synchrone Client-Schnittstelle vs. asynchrone Verarbeitung intern, CQRS-basierte Schnittstelle zwischen Backend und Clients, unterschiedliche Datenmodelle + Eventmodellierungen, starker Einfluss auf die Clientarchitektur, Umsetzung in der AWS Cloud, Verwendung des Frameworks Spring Reactor
- Um Details über zahlreiche Entwickler hinweg einheitlich umzusetzen, wurden mehrere Konzepte eingesetzt: vorgegebene Referenzimplementierungen zur Ereignisverarbeitung, einheitliche fachliche Modellierung in Enterprise Architect (Datenmodell + Eventdatenmodell + Eventfluss durch Eventprozessoren)
- Außerdem haben wir kleine Erweiterungen für Enterprise Architect geschrieben, um geeignete Sichten auf die Eventprozessoren und Events für einzelne Entwickler und ihre Aufgaben zu erzeugen
- Damit haben sowohl Entwickler im Backend als auch für 3 Clients (Android, iOS, Web) + Things-Entwickler gearbeitet und aufgrund der Detailtreue eine reibungslose Integration ermöglicht
- Obwohl insgesamt agil entwickelt wurde, hat sich die Investition in eine saubere Daten- und Eventmodellierung voll ausgezahlt
- Es hat sich gezeigt, dass die Abstimmung vieler Details zwischen Architekten und Entwicklern absolut nötig war und eine konsistente Umsetzung durch Tool-Unterstützung signifikant besser wurde
- Eine klare Trennung, wo unsere Konzepte zur Ereignisorientierung Architektur oder Detailed Design sind, ist eigentlich nicht trennscharf möglich