Überblick – Projekte und Praxis richtig einordnen.
Kernaussage: Saubere Architektur reduziert technische Schulden, vereinfacht Änderungen und erhöht die Wartbarkeit – auch in kleinen IT‑Teams von KMU lässt sich das in wenigen konkreten Schritten erreichen.
Warum Saubere Architektur wichtig ist
Saubere Architektur stellt klare Grenzen zwischen Geschäftslogik, Schnittstellen und Infrastruktur her. Für KMU bedeutet das weniger Ausfallrisiko, schnellere Lieferzyklen und geringere Kosten bei Anpassungen. Typische Begriffe sind Schichten, Abstraktion, Abhängigkeiten und Schnittstellen. In der Praxis heisst das: das Rechnungsmodell darf nicht direkt Datenbankdetails kennen; die API‑Schicht soll nur für Kommunikation zuständig sein.
Grundprinzipien und einfache Regeln
Behandle Business‑Logik als Herzstück. Modelle, Regeln und Use Cases gehören in eine zentrale Schicht, unabhängig von Web‑Frontend oder Datenbank. Abhängigkeiten zeigen einzig nach innen: Infrastruktur kennt die Geschäftslogik, nicht umgekehrt. Verwende klar definierte Schnittstellen und DTOs, um Datenübergaben zu isolieren. Kleinere Teams profitieren von einfachen Regeln: maximal drei Schichten (Präsentation, Domäne, Infrastruktur) und kurze, getestete Methoden.
Konkrete Umsetzung im KMU‑Alltag
Beispiel 1: Rechnungsstellung. Erstelle ein Invoice‑UseCase, das Beträge prüft und Zustände ändert. Die Datenbank ist eine Implementierung des InvoiceRepository‑Interfaces. So kannst du später die Persistenz ändern ohne das UseCase anzupassen. Beispiel 2: Bestellprozess im Onlineshop. Trenne das Payment‑Gateway in eine Zahlungsadapter‑Schicht. Tests für das Bestell‑UseCase bleiben stabil, weil das Gateway gemockt wird. Nutze einfache Patterns: Abhängigkeitseinjektion, Repository, Factory für komplexe Objekte.
Testing und Wartung
Schreibe Unit‑Tests für Use Cases und Integrationstests für End‑to‑End‑Flüsse. Tests dokumentieren Verhalten und verhindern Regressionen. In KMU mit begrenzten Ressourcen fokussiere auf kritische Pfade: Zahlungen, Rechnungen, Benutzer‑Authentifikation. Automatisiere Tests in der CI‑Pipeline, aber halte Builds schnell: schnelle Feedbackzyklen sind wichtiger als vollständige Testdecken.
Typische Fehler und Korrekturen
Fehler 1: Geschäftslogik in Controllern oder Datenbanktriggern. Korrektur: Extrahiere Use Cases in eigene Klassen und definiere Repository‑Interfaces. Verschiebe Validierung und Regeln in die Domänenlogik.
Fehler 2: Direkte Abhängigkeit auf konkrete Bibliotheken in der Domäne. Korrektur: Erzeuge Abstraktionen (Interfaces) und implementiere Adapter in der Infrastruktur. Sprich: Domain kennt keine JDBC‑ oder ORM‑Klassen.
Fehler 3: Zu grosse, ungetestete Klassen (God‑Objects). Korrektur: Zerlege Funktionen nach Verantwortlichkeit, schreibe Unit‑Tests für kleine Teile und dokumentiere Verantwortungsgrenzen.
Organisatorische Anpassungen
Schaffe klare Verantwortlichkeiten zwischen Produkt, Entwicklung und Betrieb. Kleine Teams erreichen Sauberkeit durch einfache Regeln: Code‑Reviews auf Abhängigkeitsrichtung, Checklisten für neue Module, und verpflichtende Tests für neue Use Cases. Führe einmal monatlich eine technische Retrospektive durch, um angefallene technische Schulden zu priorisieren.
14–30‑Tage‑Handlungsanleitung
Tag 1–3: Identifiziere drei kritische Geschäftsprozesse (z. B. Rechnungen, Bestellungen, Benutzerverwaltung). Notiere die beteiligten Klassen und Schnittstellen.
Tag 4–7: Markiere Stellen, wo Geschäftslogik in Infrastruktur oder Präsentation liegt. Wähle einen Prozess für Refactoring.
Tag 8–14: Extrahiere Use Cases und Repository‑Interfaces für diesen Prozess. Schreibe Unit‑Tests für Use Cases.
Tag 15–20: Implementiere Infrastrukturadapter (Datenbank, Zahlungsanbieter) als konkrete Klassen, die die Interfaces nutzen. Führe Integrationstests durch.
Tag 21–24: Code‑Review und Team‑Workshop: besprecht Abhängigkeitsrichtungen und die neuen Schnittstellen. Aktualisiert Architektur‑Checkliste.
Tag 25–30: Automatisiere die Tests in der CI, priorisiere weitere Prozesse für das nächste Refactoring‑Intervall und dokumentiere Lessons Learned.
Diese Schritte sind pragmatisch und sofort ausführbar. Saubere Architektur ist kein Luxus, sondern ein Betriebsmittel, das KMU stabiler, anpassungsfähiger und kosteneffizienter macht.
Kommentare