Architektur ist kein Diagramm
Software-Architektur wird oft mit Boxen und Pfeilen gleichgesetzt. Aber Architektur sind die Entscheidungen, die schwer rückgängig zu machen sind — und die den Rahmen für alles Weitere setzen.
Hier sind die fünf Entscheidungen, die den größten Einfluss auf den Erfolg eines Softwareprojekts haben.
1. Synchron oder Asynchron?
Die fundamentalste Entscheidung: Kommunizieren Ihre Komponenten synchron (Request/Response) oder asynchron (Events/Messages)?
Synchron (REST, gRPC):
- Einfacher zu verstehen und zu debuggen
- Direkte Fehlermeldung an den Aufrufer
- Enge Kopplung zwischen Sender und Empfänger
Asynchron (Kafka, RabbitMQ, SQS):
- Lose Kopplung, höhere Resilienz
- Natürliche Skalierbarkeit durch Queues
- Komplexeres Fehlerhandling, Eventual Consistency
Empfehlung: Starten Sie synchron und führen Sie Asynchronität gezielt ein, wo sie Probleme löst — nicht als Grundsatzentscheidung.
2. Datenhoheit: Shared Database oder Database per Service?
Teilen sich Ihre Services eine Datenbank — oder hat jeder Service seine eigene?
| Aspekt | Shared DB | DB per Service |
|---|---|---|
| Konsistenz | Einfach (Transaktionen) | Komplex (Sagas) |
| Kopplung | Hoch (Schema-Änderungen betreffen alle) | Niedrig |
| Performance | Joins möglich | Kein Cross-Service-Join |
| Betrieb | Ein Cluster | Mehrere Cluster |
Die Wahrheit: Die meisten Systeme brauchen einen Mittelweg. Logische Trennung (eigenes Schema pro Service) mit physisch geteilter Infrastruktur ist oft der pragmatische Start.
3. Deployment-Einheit: Monolith, Modulith oder Microservices?
Diese Entscheidung bestimmt Ihre gesamte Infrastruktur, CI/CD-Pipeline und Team-Organisation:
- Monolith: Ein Artefakt, einfaches Deployment, ein Team
- Modulith: Ein Artefakt mit klaren internen Grenzen, mehrere Teams möglich
- Microservices: Mehrere Artefakte, unabhängiges Deployment, Team-pro-Service
Die Entscheidung hängt weniger von der Technik ab als von der Teamgröße und -struktur (Conway’s Law).
4. Frontend-Architektur: Server-Rendered oder SPA?
Oft unterschätzt, aber schwer zu ändern:
Server-Side Rendering (Thymeleaf, JSF, HTMX):
- Weniger Komplexität, kein separater Build-Prozess
- SEO-freundlich out of the box
- Gut für content-lastige Anwendungen
Single Page Application (React, Angular, Vue):
- Reichere Interaktivität
- Eigenes Team für Frontend möglich
- API-first ermöglicht mehrere Clients (Web, Mobile)
Trend: HTMX und Server Components (React) bringen die Welten zusammen.
5. Fehlerbehandlungsstrategie
Die am häufigsten vergessene Architekturentscheidung: Was passiert, wenn etwas schiefgeht?
Definieren Sie frühzeitig:
- Circuit Breaker: Wann wird ein abhängiger Service als „down“ betrachtet?
- Retry-Strategie: Wie oft, mit welchem Backoff?
- Fallback-Verhalten: Degraded Mode oder Fehlerseite?
- Timeout-Budgets: Wie lange darf ein Request maximal dauern?
Ohne diese Entscheidungen wird Ihr System bei der ersten Störung kaskadierend ausfallen.
Architektur-Entscheidungen dokumentieren
Nutzen Sie Architecture Decision Records (ADRs) — kurze Dokumente, die festhalten:
- Kontext: Welches Problem lösen wir?
- Entscheidung: Was haben wir entschieden?
- Konsequenzen: Was folgt daraus (positiv und negativ)?
# ADR-001: Asynchrone Kommunikation für Bestellprozess
Kontext
Der Bestellprozess muss 5 nachgelagerte Systeme benachrichtigen.
Synchrone Aufrufe führen zu Timeouts bei Last.
Entscheidung
Wir verwenden Apache Kafka für die Event-basierte
Kommunikation im Bestellprozess.
Konsequenzen
+ Lose Kopplung, keine kaskadierenden Fehler
+ Natürliche Skalierbarkeit
- Eventual Consistency, kein sofortiges Feedback
- Zusätzliche Infrastruktur (Kafka Cluster)
Fazit
Gute Architektur entsteht nicht durch die Wahl des richtigen Frameworks, sondern durch bewusste Entscheidungen an den richtigen Stellen. Nehmen Sie sich Zeit für diese fünf Weichenstellungen — sie bestimmen den Erfolg Ihres Projekts mehr als jede Technologiewahl.
Bei CGS IT Solutions unterstützen wir Sie als Software-Architekten bei genau diesen Entscheidungen — pragmatisch, erfahrungsbasiert und technologieneutral.