Überblick – Projekte und Praxis richtig einordnen.
Kernaussage: Saubere Architektur schafft klare Schichten, reduziert technische Schulden und macht Wartung im KMU-Alltag planbar. Mit kleinen, konsequenten Schritten lassen sich bestehende Systeme innerhalb weniger Wochen deutlich verbessern.
Warum Saubere Architektur für KMU relevant ist
Saubere Architektur trennt Geschäftslogik, Schnittstellen und Infrastruktur. Das reduziert Abhängigkeiten zwischen Modulen und macht Änderungen sicherer. KMUs profitieren durch schnellere Anpassungen an Kundenwünsche, niedrigere Betriebskosten und geringere Ausfallrisiken. In der Praxis heisst das: ein Modul für Domänenregeln, eines für Anwendungsfälle, eines für Schnittstellen (z. B. Web-API) und eines für die Persistenz (Datenbank, Dateien).
Konkrete Struktur und Verantwortlichkeiten
Definieren Sie klare Schichten: Domäne (Entities, Geschäftsregeln), Anwendungsfall (Use Cases), Schnittstelle (Adapter, Controller) und Infrastruktur (Datenbank, Externe Dienste). Jede Schicht hat nur genau definierte Abhängigkeiten — immer nach innen. Beispiel aus dem KMU-Alltag: Die Angebote-Logik (Domäne) darf nicht direkt Datenbank-Queries ausführen; stattdessen ruft sie ein Repository-Interface, das von der Infrastruktur implementiert wird.
Technische Umsetzung mit kleinen Schritten
Beginnen Sie mit einem kritischen Modul: Auftragsverwaltung oder Kundenstamm. Extrahieren Sie Geschäftslogik in Domänenklassen. Definieren Sie Interfaces für Persistenz und Integrationen. Implementieren Sie Adapter, die diese Interfaces erfüllen. Nutzen einfache Tests für Use Cases (Unit-Tests) und für Adapter (Integrationstests gegen eine Testdatenbank). Beispiel: Beim Bestellprozess wird die Rabattberechnung in einer Domänenklasse gekapselt und über ein Interface in bestehende Checkout-Controller eingebunden.
Typische Fehler und Korrekturen
Fehler: Mischmasch aus UI-Logik und Geschäftsregeln in Controllern.
Fehler: Repository-Implementierungen werden überall neu kopiert.
Fehler: Tests prüfen nur End-to-End ohne Isolation.
Praxisbeispiele aus KMU-Projekten
Eine Bäckerei-Software trennte anfänglich Preisregeln, Lager und Kassiervorgang nicht. Durch Einführung von Domänenklassen für Preislogik konnten neue Rabatte ohne Datenbankänderung implementiert. Ein mittelständischer Dienstleister isolierte E-Mail-Sende-Adapter; beim Wechsel des Mailproviders musste nur der Adapter ersetzt werden — keine Änderungen an Geschäftslogik.
Wirtschaftlicher Nutzen und Messgrössen
Messen Sie Verbesserungen an Reaktionszeit für Feature-Anfragen, an der Anzahl von Regressionen pro Release und an der Zeit für Bugfixes. KMUs sehen oft zuerst geringere Durchlaufzeiten bei Kundenanforderungen und sinkende Fehlerkosten. Dokumentieren Sie Änderungen und halten Sie Verantwortlichkeiten klar fest.
Handlungsanleitung (14–30 Tage)
Tag 1–3: Analyse — Wählen Sie ein kritisches Modul (z. B. Auftragsverwaltung). Dokumentieren Sie aktuelle Logik, Schnittstellen und Abhängigkeiten.
Tag 4–7: Modellierung — Definieren Sie Domänenklassen, Use Cases und notwendige Interfaces (Repository, ExternalService). Skizzieren Sie die Schichten.
Tag 8–12: Extraktion — Verschieben Sie Geschäftsregeln aus Controllern in Domänenklassen. Ersetzen Sie direkte DB-Zugriffe durch Repository-Interfaces.
Tag 13–18: Adapterentwicklung — Implementieren Sie Infrastruktur-Adapter (DB, API-Clients). Schreiben Sie einfache Integrationstests für diese Adapter.
Tag 19–22: Testen — Ergänzen Sie Unit-Tests für Use Cases mit Mocks. Führen Sie Integrations- und Regressionstests aus.
Tag 23–26: Rollout — Setzen Sie die Änderungen in einer Staging-Umgebung ein. Überwachen Sie Fehler und Performance.
Tag 27–30: Review und Wissenstransfer — Sammeln Sie Lessons Learned, aktualisieren Sie Architekturrichtlinien und schulen das Team auf die neuen Schichten.
Diese Schritte reduzieren Risiken und liefern in wenigen Wochen spürbare Verbesserungen. Bleiben Sie konsequent bei Abhängigkeiten nach innen und priorisieren Sie kleine, getestete Änderungen vor grossen Rewrites.
Kommentare