System Structure
Beschreibt die statische und logische Gliederung eines Systems in Komponenten, Schnittstellen und Interaktionsmuster zur strukturierten Gestaltung und Kommunikation.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Falsche Grenzziehung führt zu erhöhtem Kopplungsaufwand
- Unklare Ownership erzeugt Verzögerungen bei Änderungen
- Übermäßige Vereinfachung übersieht Betriebsanforderungen
- Dokumentiere Annahmen, Grenzen und offene Fragen explizit
- Nutze standardisierte Darstellungsformen (z. B. Komponenten-, Sequenzdiagramme)
- Führe regelmäßige Architektur-Reviews und technische Retrospektiven durch
I/O & Ressourcen
- Geschäftsanforderungen und Domänenmodell
- Bestehende Systemdokumentation und Codebasis
- Betriebsanforderungen (Verfügbarkeit, Performance)
- Architekturdokumente und Komponentendiagramme
- Vertragsspezifikationen für Schnittstellen
- Empfehlungen für Deploy- und Betriebsmodelle
Beschreibung
System Structure beschreibt die statische und logische Gliederung eines Softwaresystems, einschließlich Komponenten, Schnittstellen und Interaktionsmustern. Es liefert ein abstraktes Modell zur Systemgestaltung und Entscheidungsfindung über Grenzen, Verantwortung und Deploy-Ebenen. Es unterstützt Dokumentation, Architektur-Reviews und die Abstimmung zwischen Teams.
✔Vorteile
- Verbesserte Wartbarkeit durch klare Struktur
- Bessere Teamabstimmung und Verantwortungszuweisung
- Erleichtert Skalierung und gezielte Optimierungen
✖Limitationen
- Initialer Abstimmungs- und Dokumentationsaufwand
- Kann zu Overhead führen, wenn zu fein zergliedert
- Nicht alle Laufzeitaspekte sind statisch sichtbar
Trade-offs
Metriken
- Anzahl der Schnittstellenänderungen
Misst wie oft APIs/Schnittstellen angepasst werden; Indikator für Stabilität der Struktur.
- Zeit bis zum Deploy einer Komponente
Zeit vom Commit bis zum produktiven Einsatz einer Komponente; misst Deploy-Autonomie.
- Fehlerverbreitung über Komponenten
Anteil von Incidents, die mehrere Komponenten betreffen; Indikator für Kopplung.
Beispiele & Implementierungen
Monolith zu modularer Architektur
Aufteilung eines großen Monolithen in klar abgegrenzte Module mit definierten Schnittstellen.
Layered-Architektur für Geschäftsapplikation
Einsatz Schichtenmodell (Präsentation, Domäne, Persistenz) zur Trennung von Anliegen.
Microservices mit klaren API-Grenzen
Definition von Service-Grenzen, Dateneigentum und Kommunikationsmustern für Microservices.
Implementierungsschritte
Bestehende Architektur analysieren und relevante Artefakte sammeln
Kernkomponenten, Schnittstellen und Verantwortlichkeiten definieren
Architekturdokumente erstellen und mit Stakeholdern reviewen
Governance und Entscheidungsprozesse für zukünftige Änderungen etablieren
⚠️ Technische Schulden & Engpässe
Tech Debt
- Alte Monolith-Module ohne klare Schnittstellen
- Nicht versionierte APIs im Produktionsbetrieb
- Fehlende Observability in kritischen Pfaden
Bekannte Engpässe
Beispiele für Missbrauch
- Vollständige Modulzerlegung ohne Berücksichtigung ops-relevanter Anforderungen
- Festlegung von Architektur nur anhand technischer Präferenzen einzelner Entwickler
- Dokumentation bleibt veraltet und wird nicht gepflegt
Typische Fallen
- Vernachlässigung nicht-funktionaler Anforderungen
- Zu viele Ausnahmen ohne Governance führen zu Inkonsistenzen
- Unklare Ownership für Schnittstellen
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Vorhandene Legacy-Komponenten können Grenzen erzwingen
- • Regulatorische Anforderungen an Datenhaltung
- • Begrenzte Ressourcen für umfassende Umstrukturierung