Trennung von Verantwortlichkeiten (Separation of Concerns)
Architekturprinzip zur gliedernden Aufteilung eines Systems in klar abgegrenzte Verantwortungsbereiche zur Verbesserung von Wartbarkeit, Testbarkeit und Wiederverwendung.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Fehlende Konsistenz bei Schnittstellen führt zu Integrationsproblemen
- Überdesign durch zu feingranulare Trennung
- Nicht beachtete Querschnittsanforderungen (z. B. Logging)
- Kleine, durchdachte Schnittstellen statt großer APIs
- Automatisierte Tests pro Modul
- Klare Eigentümerschaft der Verantwortungsbereiche
I/O & Ressourcen
- Domänenmodell oder Geschäftslogikbeschreibung
- Bestehende Codebasis oder Architekturübersicht
- Non-functional requirements (Performance, Sicherheit)
- Modul- und Schichtdiagramme mit Verantwortlichkeiten
- Definierte Schnittstellenverträge
- Testbare, austauschbare Implementierungseinheiten
Beschreibung
Separation of Concerns (SoC) ist ein Architekturprinzip, das Systeme in klar abgegrenzte Verantwortungsbereiche trennt, um Wartbarkeit und Testbarkeit zu verbessern. Es fördert lose Kopplung und hohe Kohäsion, erleichtert parallele Entwicklung sowie Wiederverwendung und reduziert Komplexität und erleichtert Refactoring.
✔Vorteile
- Bessere Wartbarkeit durch isolierte Module
- Erhöhte Testbarkeit einzelner Komponenten
- Parallele Entwicklung und Wiederverwendung
✖Limitationen
- Initialer Mehraufwand für Design und Schnittstellen
- Übermäßige Fragmentierung kann Komplexität erhöhen
- Nicht überall sinnvoll (sehr kleine Systeme)
Trade-offs
Metriken
- Modulkopplung
Grad der Abhängigkeiten zwischen Modulen; niedriger ist besser.
- Kohäsion
Maß für inhaltliche Zusammengehörigkeit innerhalb eines Moduls.
- Anzahl durchgeführter Refactorings
Zählt Refactorings zur Einhaltung von SoC-Prinzipien und deren Auswirkungen.
Beispiele & Implementierungen
Layered Webshop
Ein Onlineshop trennt Präsentation, Geschäftslogik und Datenzugriff in separate Module zur vereinfachten Wartung.
Microservices für Zahlungsabwicklung
Zahlungsfunktionen werden als eigenständiger Service implementiert, um Verantwortlichkeiten und Skalierung zu isolieren.
API- und UI-Trennung
Ein Backend stellt APIs bereit, während verschiedene UIs (Web, Mobile) unabhängig entwickelt werden können.
Implementierungsschritte
Analyse ist die Basis: Verantwortlichkeiten identifizieren.
Grenzen definieren: Module, Schichten und Schnittstellen festlegen.
Iteratives Extrahieren und Testen von Komponenten.
Governance einrichten: Contracts, Versioning und Dokumentation sicherstellen.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Ungenaue Modulgrenzen, die spätere Refactorings erzwingen
- Veraltete Schnittstellen ohne Deprecation-Plan
- Fehlende Testabdeckung an Modulgrenzen
Bekannte Engpässe
Beispiele für Missbrauch
- Trennung nach Technologie statt nach Verantwortung (z. B. alle Datenzugriffs-Tools in einem Modul)
- Schnittstellen ohne Versionierungsstrategie verwenden
- Querschnittsanforderungen ignorieren (Security, Logging)
Typische Fallen
- Zu frühe oder zu feine Aufteilung ohne klare Anforderungen
- Fehlende Dokumentation der Module und Schnittstellen
- Widersprüchliche Verantwortlichkeiten zwischen Teams
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Legacy-Code mit starken Abhängigkeiten
- • Begrenzte Ressourcen für Refactoring
- • Notwendigkeit der Rückwärtskompatibilität