Aufbau Softwarearchitektur - Systeme gezielt modernisieren

Gewachsene monolithische Anwendungen erschweren Änderungen, wenn Verantwortlichkeiten, Abhängigkeiten und Systemgrenzen nicht mehr klar erkennbar sind. Eine Aufteilung in Microservices löst diese Probleme nicht automatisch und kann durch Netzwerkkommunikation, verteilte Fehlerfälle und zusätzlichen Betriebsaufwand neue Komplexität erzeugen. Entscheidend ist daher, Modul- und Servicegrenzen aus konkreten Architekturproblemen abzuleiten und ihre Konsequenzen systematisch zu bewerten.

Im Mittelpunkt der Weiterbildung steht die schrittweise Modernisierung einer gewachsenen Softwarearchitektur. An einer realistischen Bildverarbeitungsanwendung analysieren Sie zunächst den bestehenden Monolithen und entwickeln daraus begründete Architekturentscheidungen für Modularisierung, Schnittstellen, Kommunikation und eine mögliche Verteilung. Dabei steht nicht eine bestimmte Zielarchitektur im Vordergrund, sondern die strukturierte Bewertung unterschiedlicher Lösungsoptionen und ihrer Trade-offs.

Nach der Weiterbildung können Sie:

• problematische Abhängigkeiten und Verantwortlichkeiten in gewachsenen Softwarearchitekturen analysieren
• geeignete Modulgrenzen für einen Modular Monolith identifizieren
• Schnittstellen und Kommunikationsformen für konkrete Systemgrenzen auswählen
• die Herauslösung eines Moduls als eigenständigen Service fundiert bewerten
• wesentliche Architekturentscheidungen und das daraus entstehende Zielbild nachvollziehbar dokumentieren

Nutzen der Weiterbildung

Die Weiterbildung erhöht die Entscheidungssicherheit bei der Weiterentwicklung gewachsener Softwaresysteme. Architekturentscheidungen lassen sich stärker an konkreten Problemen und Konsequenzen statt an technologischen Trends ausrichten. Dies reduziert unnötige strukturelle Komplexität und unterstützt eine schrittweise, nachvollziehbare Weiterentwicklung bestehender Anwendungen.

Montag, 21. und Dienstag, 22. Juni 2027
9:00 Uhr bis 16:30 Uhr, inkl. Pausen

1. Bestehenden Monolithen analysieren

Leitfrage: Wo liegen in einem gewachsenen System die tatsächlichen Probleme?

Inhalte:

• vorhandene Verantwortlichkeiten
• fachliche und technische Abhängigkeiten
• problematische Kopplungen
• Änderungsgrenzen
• sinnvolle Kandidaten für eine Modularisierung

Praxis:
Analyse der bestehenden Bildverarbeitungsanwendung und gemeinsames Herausarbeiten problematischer Stellen.

2. Modular Monolith entwickeln

Leitfrage: Wie kann ich einen bestehenden Monolithen so strukturieren, dass Änderungen innerhalb klarer Grenzen bleiben?

Inhalte:

• Modulgrenzen
• Abhängigkeiten zwischen Modulen
• interne Schnittstellen
• Modular Monolith als bewusstes Architekturziel
• Hexagonal, Clean und Onion Architecture im kurzen Gegenüber als mögliche Lösungsansätze
• SOLID und Dependency Injection dort, wo sie konkret zur Entkopplung beitragen

Praxis:
Die Teilnehmer entwickeln eine modulare Zielstruktur für die Bildverarbeitungsanwendung.

3. Schnittstellen und Kommunikation

Leitfrage: Wie müssen Schnittstellen gestaltet sein, damit die neue Struktur tatsächlich wartbarer wird?

Inhalte:

• synchrone und asynchrone Kommunikation
• REST und gRPC
• Messaging und Pub/Sub
• API-Versionierung
• Rückwärtskompatibilität
• OpenAPI
• grundlegende Anforderungen an Authentifizierung und Autorisierung an einer ausgewählten Schnittstelle

Praxis:
Entwurf und Dokumentation einer konkreten Schnittstelle zwischen zwei Verarbeitungskomponenten.

4. Vom Modul zum verteilten Service

Leitfrage: Welche Grenze sollte tatsächlich über einen Prozess hinweg gezogen werden?

Zunächst werden die Kriterien für und gegen eine Verteilung betrachtet.

Für eine Herauslösung können beispielsweise sprechen:

• unabhängige Skalierung
• unterschiedliche Lebenszyklen
• technische Isolation
• organisatorische Grenzen
• Deployment-Unabhängigkeit

Dagegen sprechen beispielsweise:

• zusätzliche Netzwerklatenz
• verteilte Fehlerfälle
• komplexere Observability
• zusätzliche Deployment-Komplexität
• Schnittstellen- und Versionsaufwand
• höherer Betriebsaufwand

Praxis:
Ein geeigneter Verarbeitungsschritt wird als Kandidat für eine Herauslösung untersucht. Das Ergebnis kann ausdrücklich auch sein: Der Schritt sollte nicht als Microservice herausgelöst werden. Gerade diese Entscheidung ist Bestandteil des Lernziels.

5. Event-driven Architecture gezielt einsetzen

Event-driven Architecture wird nur dort eingesetzt, wo sie im Praxisprojekt einen konkreten Vorteil bietet.

Betrachtet werden:

• Events und Commands
• Entkopplung von Verarbeitungsschritten
• synchrone versus ereignisbasierte Kommunikation
• Konsequenzen für Fehlerbehandlung und Schnittstellen

Praxis:
Für einen ausgewählten Verarbeitungsschritt wird geprüft, ob eine Ereignis-basierte Kommunikation gegenüber einem direkten Aufruf Vorteile bringt.

6. Architektur dokumentieren

Die Dokumentation entsteht parallel zur Entwicklung des Systems.

Verwendet werden:

• C4-Modell
• ausgewählte Teile von arc42
• Architecture Decision Records

Im Mittelpunkt stehen nicht vollständige Dokumentationsmodelle, sondern die Nachvollziehbarkeit der wesentlichen Entscheidungen.

Praxis:
Dokumentation der Ausgangsarchitektur, der wesentlichen Entscheidungen und des Zielbilds.