Schritt für Schritt – kompakt erläutert.
Kernaussage: Saubere Architektur reduziert Komplexität und erhöht Wartbarkeit, wenn Schichten klar getrennt, Abhängigkeiten kontrolliert und Geschäftsregeln unverändert bleiben.
Warum saubere Architektur für KMU relevant ist
Saubere Architektur verhindert, dass Code zu einem Risiko für den Geschäftsbetrieb wird. KMU ändern Geschäftsprozesse schnell. Wenn Architektur sauber ist, lassen sich Änderungen lokal umsetzen, Tests bleiben stabil und neue Teammitglieder finden sich schneller zurecht. Wesentliche Begriffe sind Schichten, Abhängigkeitsregel, Port-Adapter-Prinzip und Geschäftslogik. Diese Elemente sorgen dafür, dass technische Details wie Datenbanken oder Frameworks die Kerngeschäftsregeln nicht verschmutzen.
Grundprinzipien kurz und konkret
Trenne Geschäftslogik von Infrastruktur. Geschäftsregeln gehören in Domänenschichten, nicht in Benutzeroberfläche oder Persistenz. Richte Abhängigkeiten nach innen: höhere Ebenen dürfen niedrigere kennen, nicht umgekehrt. Verwende Schnittstellen (Ports) für externe Dienste und Adapter, damit Austausch möglich ist. Nutze einfache Paketzuschnitte: Domäne, Anwendungsfälle, Schnittstellen, Infrastruktur. In einem ERP- oder CRM-Projekt bedeutet das: Kalkulationslogik bleibt in der Domäne, Datenbankzugriffe über Repositories (Port), UI-Aufrufe passieren über Use Cases.
Praxisbeispiele aus dem KMU-Alltag
Beispiel 1 — Auftragsverwaltung: Implementiere die Auftragsvalidierung in der Domäne. Ein Webcontroller ruft einen Use Case auf, der die Geschäftsregeln prüft und ein Repository-Port benutzt. So kannst du die Datenbank wechseln, ohne Validierungslogik anzufassen.
Beispiel 2 — Schnittstelle zu Buchhaltung: Definiere ein Port-Interface für Zahlungen. Adapter zur Buchhaltungssoftware implementieren dieses Interface. Tests simulieren Zahlungen ohne Produktivsystem.
Beispiel 3 — Reporting: Erstelle eigens ein Read-Model für Berichte, statt Abfragen die Domäne zu vermischen. Das reduziert Seiteneffekte und verbessert Performance.
Typische Fehler und wie man sie korrigiert
Fehler 1: Geschäftslogik in Controllern oder UI. Korrektur: Verschiebe Logik in Use-Case- oder Domänenschichten. Erstelle klare Service- oder Use-Case-Klassen und teste sie unabhängig.
Fehler 2: Direkte Abhängigkeit von Infrastruktur in der Domäne (z. B. Datenbank-ORM in Domänenklassen). Korrektur: Definiere Repository- oder Gateway-Interfaces in der Domäne und implementiere die Infrastruktur in separaten Adaptern. Inversion of Control oder einfache Fabriken helfen beim Zusammenbau.
Fehler 3: Zu grosse Pakete statt durchdachter Schichten. Korrektur: Zerlege das System in kleine, kohärente Module (z. B. Domäne, Use Cases, Ports, Adapter). Setze einfache Namenskonventionen und prüfe Abhängigkeiten mit statischen Tools.
Konkrete Techniken und Werkzeuge
Beginne mit einer Architektur-Map: zeichne Komponenten und Abhängigkeiten. Verwende Code-Reviews, die explizit auf Schichtverletzungen prüfen. Schreibe Unit-Tests für Domänenlogik und Integrationstests für Adapter. Nutze Dependency-Injection für den Laufzeitzusammenbau. Verwende einfache Schnittstellennamen (z. B. IAuftragsRepository) und dokumentiere Kontrakte kurz mit Beispielen. Statistische Abhängigkeitsanalysen (z. B. mit Build-Tools) helfen, Schmutz zu finden.
Wirtschaftlicher Nutzen und schnelle Wins
Ein sauberer Aufbau reduziert Zeitaufwand bei Anpassungen. Ein typischer kleiner Gewinn: Ein Wechsel der Zahlungsplattform kostet bei sauberer Architektur Stunden statt Tage. Tests verhindern Regressionen und sparen Supportkosten. Priorisiere kritische Use Cases, dann refactore inkrementell. Kleine, sichtbare Verbesserungen schaffen Akzeptanz im Team.
Handlungsanleitung 14–30 Tage (nummerierte Schritte)
Tag 1–2: Erstelle eine einfache Architektur-Map der aktuellen Anwendung. Markiere Domäne, Use Cases, Schnittstellen, Adapter.
Tag 3–6: Identifiziere 2–3 kritische Use Cases (z. B. Auftrag anlegen, Zahlung verarbeiten). Schreibe für jeden eine kurze Spec: Eingaben, Geschäftsregeln, gewünschtes Verhalten.
Tag 7–10: Extrahiere die Geschäftslogik eines Use Cases in eine Use-Case- oder Domänenklasse. Lege Interfaces (Ports) für Repositories/Services an. Schreibe Unit-Tests für diese Logik.
Tag 11–15: Implementiere Adapter für bestehende Infrastruktur, die die neuen Ports erfüllen. Führe Integrationstests durch. Ev. bestehende Klassen schrittweise ersetzen.
Tag 16–20: Führe Code-Reviews mit Fokus Schichttrennung durch. Behebe Schichtverletzungen. Ergänze einfache statische Abhängigkeitsprüfungen in der Build-Pipeline.
Tag 21–25: Wiederhole Extraktion für den nächsten Use Case. Priorisiere nach Business-Impact. Dokumentiere Konventionen (Pakete, Schnittstellennamen).
Tag 26–30: Mache einen kurzen Workshop mit dem Team: Ziele, neue Struktur, Regeln für Abhängigkeiten. Plane nächste Iteration und messe Aufwand und Nutzen.
Diese Schritte liefern innerhalb eines Monats spürbare Verbesserungen. Bleibe inkrementell, messe Auswirkungen und halte Geschäftslogik strikt getrennt von Infrastruktur. Das senkt langfristig Kosten und erhöht Änderbarkeit.
Kommentare