Vom Code zur Architektur: Warum Software mehr ist als nur Funktionalität

Die Entwicklung von Software reduziert sich für viele Entwickler:innen auf das Schreiben von Code: Funktionen implementieren, Datenbanken anbinden, Formulare validieren. Doch der eigentliche Test beginnt lange vor der ersten Zeile – in der Frage, welche Architektur für das konkrete Problem die richtige ist. Im Rahmen eines Hochschulprojekts sollte ein klinisches Verwaltungssystem entstehen, das zunächst als MVP für eine einzelne Praxis begann und später zu einer skalierbaren SaaS-Plattform für mehrere Kliniken werden sollte. Obwohl es sich um eine akademische Übung handelte, vermittelte das Projekt wertvolle Einblicke: Softwareentwicklung ist mehr als nur Codieren, sondern das Abwägen von Geschäftsanforderungen, Kosten, Sicherheit und Skalierbarkeit. Die zentrale Erkenntnis lautete: Die beste Architektur ist die, die zur aktuellen Phase des Produkts passt.

Warum Komplexität zu Beginn oft kontraproduktiv ist

Zu Projektbeginn lag die Versuchung nahe, direkt eine hochgradig skalierbare Architektur umzusetzen: Microservices, Event-Queues, Kubernetes und verteilte Datenbanken. Doch bei genauerer Betrachtung der Ausgangslage erwies sich dieser Ansatz als übertrieben. Das System sollte zunächst für eine einzige Klinik mit begrenztem Budget und noch unklaren Anforderungen entwickelt werden. Eine Microservices-Architektur hätte in dieser Phase mehr Probleme verursacht als gelöst: zusätzliche Komplexität bei der Kommunikation zwischen Services, Versionierungskonflikte, verteilte Fehlerbehebung und höhere Infrastrukturkosten. Daher entschieden wir uns für eine schichtweise Architektur, die als einzelner Prozess deployed wurde. Diese Struktur ermöglichte eine klare Trennung der Verantwortlichkeiten, ohne gleich die Komplexität eines verteilten Systems einzuführen.

Die Präsentationsschicht umfasste API-Endpunkte, Controller und Authentifizierungslogik. Die Anwendungsschicht konzentrierte sich auf Use Cases wie Patientenverwaltung, Terminbuchung und Dokumentation. Die Infrastrukturschicht kümmerte sich um Datenpersistenz in PostgreSQL, Repositorys und die Integration mit WhatsApp. Dieser Ansatz widerlegte den Mythos, dass Monolithen grundsätzlich schlecht sind. Im Gegenteil: Ein gut strukturierter Monolith kann die ideale Architektur sein, solange er klare Modulgrenzen einhält und mit dem Projekt mitwächst. Entscheidend war, dass wir nicht aus Unwissenheit auf Einfachheit setzten, sondern weil es die sinnvollste Lösung für die erste Phase war.

Voraussicht statt nachträglicher Komplexität

Ein weiterer zentraler Lernprozess bestand darin, frühzeitig Entscheidungen zu treffen, die später nur schwer rückgängig zu machen sind. Manche Anforderungen mögen im MVP überflüssig erscheinen, doch ihre Implementierung spart später viel Aufwand. So integrierten wir von Anfang an den Tenant-Identifier in das Datenmodell, obwohl zunächst nur eine einzige Klinik bedient wurde. Für spätere Phasen, in denen das System als SaaS für mehrere Kliniken dienen sollte, wäre das Nachrüsten von Multi-Tenancy auf bestehenden Tabellen ein riskantes Unterfangen gewesen.

Ebenso setzten wir frühzeitig auf Docker-Containerisierung, obwohl das MVP auch ohne sie hätte funktionieren können. Diese Entscheidung ermöglichte später ein einfaches Deployment in verschiedenen Umgebungen. Zusätzlich abstrahierten wir die WhatsApp-Integration durch eine Schnittstelle namens IWhatsAppSender. Dadurch konnten wir:

• Entwickler:innen den SMS-Versand in Tests simulieren,
• problemlos den Anbieter wechseln oder
• zusätzliche Nachrichtenkanäle wie E-Mail oder Push-Benachrichtigungen integrieren.

Die Erkenntnis lautete: Programmieren löst das unmittelbare Problem – Design verhindert zukünftige.

Wenn der Monolith an seine Grenzen stößt

Der Wandel von einem Monolithen zu einer Microservices-Architektur erfolgt nicht aus heiterem Himmel, sondern resultiert aus einem Veränderung der Geschäftsanforderungen. Unser System sollte nicht mehr nur eine Klinik bedienen, sondern als SaaS für mehrere Kliniken fungieren. Damit änderten sich die Anforderungen grundlegend:

• Datenisolation: Jede Klinik benötigt ihre eigenen, abgeschotteten Daten.
• Abrechnungslogik: Es mussten Abonnements, Nutzungslimits und Rechnungsstellungen eingeführt werden.
• Skalierbarkeit: Terminbuchungen verteilen sich über den Tag, während Erinnerungsnachrichten an Patienten oft in kurzen Zeitfenstern versendet werden – was zu Lastspitzen führt.

In dieser Phase zeigte der Monolith seine Grenzen. Wenn der Nachrichten-Service aufgrund hoher Last nicht reagiert, leidet die gesamte Anwendung darunter – selbst wenn die Terminbuchung davon eigentlich nicht betroffen sein sollte. Die Frage lautete daher: Warum sollte eine Terminbuchung scheitern, nur weil ein externer Dienst wie WhatsApp überlastet ist?

Diese Überlegung führte zur Aufteilung des Systems in eigenständige Services wie:

• Appointment für die Terminverwaltung,
• Notification für Benachrichtigungen,
• MedicalRecord für die Dokumentation,
• Identity für Authentifizierung,
• Tenant für die Verwaltung mehrerer Kliniken,
• Billing für Abrechnungen und
• Audit für Protokollierung.

Jeder Service hat unterschiedliche Verantwortlichkeiten, Änderungsfrequenzen und Skalierungsbedürfnisse. Diese Struktur erlaubte es, nur die betroffenen Komponenten zu skalieren, ohne die gesamte Anwendung zu belasten.

Event-basierte Kommunikation: Separation von Fakten und Nebenwirkungen

Ein besonders anspruchsvoller architektonischer Aspekt war der Übergang von einer synchronen zu einer eventbasierten Kommunikation. Im synchronen Modell führt die Buchung eines Termins zu einer Kette von HTTP-Aufrufen: Datenvalidierung, Patientenabfrage, Tenant-Konfiguration, Benachrichtigung und Audit-Protokollierung. Fällt einer dieser Services aus, scheitert die gesamte Transaktion.

Mit Events verändert sich die Logik grundlegend. Der Terminbuchungs-Service sendet zunächst ein AppointmentBooked-Event in eine Warteschlange. Die Benachrichtigungskomponente reagiert darauf mit einem asynchronen Prozess und sendet Erinnerungen an die Patienten. Der Audit-Service protokolliert die Aktion im Hintergrund. Diese Entkopplung bietet mehrere Vorteile:

• Fehlertoleranz: Fällt der Benachrichtigungs-Service aus, kann die Terminbuchung trotzdem erfolgreich abgeschlossen werden.
• Skalierbarkeit: Services lassen sich unabhängig voneinander skalieren.
• Flexibilität: Neue Konsumenten von Events können leicht hinzugefügt werden, ohne die Produzenten zu modifizieren.

Durch diesen Ansatz lernten wir, dass Architektur nicht nur die Struktur des Codes definiert, sondern auch darüber entscheidet, wie robust ein System auf unerwartete Situationen reagiert.

Die Architektur muss mit dem Produkt wachsen

Die größte Herausforderung besteht darin, nicht zu früh zu viel oder zu wenig zu planen. Eine zu einfache Architektur kann später zu kostspieligen Refactorings führen, während eine überkomplexe Struktur von Anfang an Ressourcen verschwendet. Die Kunst liegt darin, eine Basis zu legen, die mit dem Projekt mitwächst – sei es durch modulare Erweiterungen, schrittweise Einführung von Microservices oder die Integration neuer Technologien.

Am Ende des Projekts stand fest: Softwareentwicklung ist kein reines Code-Problem, sondern eine Frage der Weitsicht. Die beste Architektur ist keine, die für alle Ewigkeit gilt, sondern eine, die zur aktuellen Phase passt und sich anpassen lässt, wenn sich die Anforderungen ändern. Das nächste Mal, wenn wir vor einer ähnlichen Entscheidung stehen, werden wir uns nicht fragen: Wie lösen wir das Problem jetzt? Sondern: Wie gestalten wir es so, dass es uns auch morgen noch unterstützt?