Software-Architektur für Apps: Wenn “nur schnell” plötzlich dein Vollzeitjob wird
Warum “verteilte Verantwortung” bei Apps oft nur verteilte Probleme bedeutet (und wie ein Dialog-Manager Chaos verhindert).
Ich habe als Softwareentwickler schon so ziemlich alles gesehen: Systeme, die elegant gestartet sind und nach drei Releases klangen wie ein Einkaufswagen mit kaputtem Rad. Und ich war nicht nur Zuschauer – ich war oft Teil des Teams, das dachte:
“Zentral klingt nach Überwachung. Lass uns lieber alles dezentral lösen. Dann ist jeder verantwortlich.”
Klingt fair. Klingt modern. Klingt nach Freiheit.
In der Praxis endet es häufig wie eine WG ohne Putzplan: Alle sind zuständig – und irgendwann putzt niemand.
Dieser Artikel ist für Leute, die Software nicht nur “zum Laufen” bringen, sondern zuverlässig betreiben und weiterentwickeln müssen: Produktteams, Agenturen, CTOs, Delivery Leads. Und ja: für Entwickler, die keine Lust mehr haben, dass “kleine Anpassungen” jedes Mal eine Schnitzeljagd im Code auslösen.
Das Problem: Wenn Logik überall ist, wird jede Änderung teuer
Nehmen wir etwas Banales, das in Apps nie banal bleibt: Dialoge.
- “Login abgelaufen”
- “Neue Version verfügbar”
- “Bitte Berechtigungen geben”
- “Offline – Sync später”
- “Feature-Tour”
- “Bewerte die App”
- “Fehler beim Bezahlen”
- “Bluetooth-Gerät nicht gefunden”
Jeder Dialog hat Bedingungen. Viele davon sind kontextabhängig:
- nur wenn Nutzer eingeloggt ist
- nur wenn nicht gerade ein kritischer Flow läuft
- nur wenn noch kein anderer Dialog offen ist
- nur wenn dieser Dialog nicht schon dreimal abgelehnt wurde
- nur nach bestimmtem Ereignis, aber nicht sofort (Timing!)
Und jetzt kommt der typische Architektur-Unfall:
Statt diese Regeln an einem Ort zu verwalten, verteilen sie sich über Screens, Komponenten, Services und “Hilfsklassen”.
Das Ergebnis:
- Regeln werden dupliziert
- Dialoge konkurrieren (zwei gleichzeitig, falsche Reihenfolge, “kommt nie”)
- Änderungen werden teuer, weil du nicht weißt, wo alles hängt
- Qualität sinkt, weil niemand mehr den Gesamtfluss überblickt
Der Klassiker: Du änderst eine Regel (“Dialog X nicht während Onboarding”) und musst plötzlich an fünf Stellen nachziehen. Nicht weil das System komplex ist – sondern weil es so gebaut wurde, dass niemand zentral Verantwortung übernimmt.
Warum viele Teams “Zentralisierung” ablehnen (und warum sie damit oft recht haben)
Die Skepsis ist nicht unbegründet. Viele “zentrale” Lösungen fühlen sich so an:
- eine riesige Klasse (God Object)
- jede Ausnahme als Sonderfall
- alles hängt an einem zentralen “Manager”, den niemand anfassen will
- ein Bottleneck, der Entwicklung verlangsamt
Kurz: Zentralisierung kann missbraucht werden.
Aber das ist ein Implementationsproblem – kein Architekturprinzip.
Der entscheidende Unterschied ist:
Eine Instanz macht alles, kennt alles, entscheidet alles – und wächst ins Unendliche.
Eine Instanz koordiniert, aber besitzt die Regeln nicht allein.
Regeln sind modular (Policies), testbar und transparent.
Oder in Business-Sprache:
Wir wollen nicht Kontrolle. Wir wollen Planbarkeit.
Der Ausweg: Ein zentraler Dialog-Orchestrator (mit klarer Rollenverteilung)
Die Idee ist einfach:
- Features “melden Bedarf” (Events/Signale)
- Eine zentrale Stelle entscheidet: was, wann, unter welchen Bedingungen
- Die UI zeigt nur, was angefordert wird
- Regeln sind sauber gekapselt
Stell dir das wie Flugverkehr vor:
- Flugzeuge funken Wünsche (“Wir würden gern landen”)
- Der Tower koordiniert Reihenfolge, Prioritäten, Sicherheitsabstände
- Niemand möchte, dass jedes Flugzeug selbst entscheidet, ob gerade Landebahn frei ist
Ein Dialog-Orchestrator ist dieser Tower.
Was das konkret bringt (für Produktteams und Agenturen)
1) Weniger Risiko bei Änderungen
Neue Regel? Ein Ort. Eine Policy. Fertig.
Kein “wo hängt das überall dran”.
2) Konsistenter Nutzerfluss
Dialoge erscheinen in sinnvoller Reihenfolge. Keine Doppelungen. Kein Timing-Glitch.
3) Schnellere Lieferung trotz “mehr Architektur”
Weil du weniger Zeit mit Nebenkriegsschauplätzen verbringst.
“Warum kommt dieser Dialog nicht?” wird von einem Mystery-Game zu einem Debug-Fall.
4) Bessere Qualität und Testbarkeit
Du kannst Regeln testen wie Business-Logik:
- gegeben Kontext X
- wenn Event Y
- dann Dialog Z
Das ist Gold wert, sobald mehrere Teams oder Agentur + Kunde zusammenarbeiten.
Mustervergleich: Was oft passiert vs. was besser funktioniert
Muster A: “Jeder Screen entscheidet selbst”
Typisch: Jeder Bereich prüft selbst Bedingungen und zeigt Dialoge direkt.
Folgen: Duplication, inkonsistente Regeln, teure Änderungen.
Muster B: “Event-Bus und jeder hört mit”
Typisch: Ein Event wird “in den Raum geworfen”. Mehrere reagieren.
Folgen: Unklare Verantwortlichkeit, schwer nachvollziehbar, Reihenfolge zufällig.
Muster C (empfohlen): “Orchestrator + Policies + Queue”
Typisch: Ein Koordinator entscheidet zentral, Policies liefern Regeln, eine Queue steuert Reihenfolge/Priorität.
Folgen: Klarheit, Stabilität, weniger Chaos.
Das Wichtigste: Zentral bedeutet nicht starr – es bedeutet nachvollziehbar
Ich habe mich lange gegen “zentrales Management” gewehrt, weil es sich nach Kontrolle angefühlt hat. In Wahrheit war mein System aber nicht freier – nur unübersichtlicher.
Und dann passiert das, was du wahrscheinlich kennst:
Logik wird überall reingestreut (“nur schnell hier noch ein if”)
jede Änderung zieht eine Kette an Änderungen nach sich
niemand traut sich, aufzuräumen, weil man nie weiß, was man kaputt macht
Ein Orchestrator ist kein Kontrollwahn. Er ist die Stelle, die sagt:
“Wir sind ein Produkt, kein Zufallsgenerator.”
Eine pragmatische Faustregel (für Entscheidungen im Team)
Wenn etwas…
- über mehrere Screens/Module hinweg koordiniert werden muss,
- Prioritäten hat,
- Timing wichtig ist,
- und Regeln sich ändern,
…dann ist es Orchestrierung – und gehört nicht in 12 einzelne Komponenten.
Dialoge sind ein Paradebeispiel. Aber das gilt genauso für:
- Onboarding-Flows
- Feature Flags mit UI-Auswirkungen
- globale Error-/Offline-Strategien
- Session-Handling (Re-Login, Token Refresh)
- “nur einmal zeigen”-Hinweise
