Saubere Architektur im KMU — x25lab.com – Saubere Architektur

Kernaussage: Saubere Architektur reduziert langfristige Kosten und erhöht Änderbarkeit, wenn Geschäftsfunktionen klar getrennt, Abhängigkeiten invertiert und Schnittstellen konsequent definiert werden.

Was Saubere Architektur bedeutet

Saubere Architektur organisiert Software so, dass Geschäftslogik unabhängig von technischen Details bleibt. Zentrale Konzepte sind Schichten, Abhängigkeiten nach innen und klare Schnittstellen. Für KMU heisst das: Domäne und Use Cases an die Spitze, Infrastruktur an den Rand. Dadurch können Sie Technologien wechseln, ohne Geschäftsregeln anzupassen.

Konkrete Struktur für KMU-Projekte

Eine pragmatische Schichtenaufteilung:
Domänenschicht: Entitäten, Regeln, Validierung.

Anwendungs-/Use-Case-Schicht: Orchestriert Prozesse, koordiniert Domäne.

Schnittstellen/Ports: Abstrakte Interfaces für Persistenz, Messaging, API.

Infrastruktur/Adapter: Datenbank, Web-Framework, externe Dienste.
Beispiel: Ein KMU führt Kundenbestellungen. Die Domäne enthält Bestellung, Artikel, Lagerbestand. Use Case «Bestellung anlegen» prüft Bestand, reduziert Lager und erzeugt Rechnung. Persistenz ist über ein Interface IOrderRepository definiert. Die konkrete SQL-Implementierung lebt in der Infrastruktur. So ersetzen Sie die Datenbank ohne Anpassung der Geschäftslogik.

Praktische Regeln und Umsetzungsschritte

Definieren Sie die Domäne zuerst: Modellieren Sie Entitäten und Geschäftsregeln in einfachen Klassen oder Modulen.

Implementieren Sie Use Cases als eigenständige Services, die nur Domänenobjekte und Interfaces verwenden.

Verwenden Sie Interfaces/Abstraktionen für externe Abhängigkeiten und injizieren Sie konkrete Implementierungen. Abhängigkeitsumkehr ist zentral.

Halten Sie technische Details (ORM, HTTP, Logging) in eigenen Modulen. Schreiben Sie Adapter, die Interfaces implementieren.

Testen Sie Domäne und Use Cases isoliert mit Unit-Tests. Integrationstests decken Adapter-Interaktionen ab.

Beispiel aus dem Tagesgeschäft: Beim Austausch eines CRM-Systems bleibt die Rechnungslogik intakt, weil die Rechnungs-Use-Cases nur ein ICustomerRepository sehen. Ein neuer Adapter für das neue CRM implementiert dieses Interface.

Typische Fehler und wie Sie sie korrigieren

Fehler: Geschäftslogik im Controller oder in der Datenzugriffsschicht.

Korrektur: Verschieben Sie Regeln in die Domänenschicht. Controller sollten nur Requests validieren, Aufrufe an Use Cases weiterleiten und Antworten formulieren.

Fehler: Direkter Datenbankzugriff in Use-Case-Code (z. B. SQL in Geschäftsprozessen).

Korrektur: Definieren Sie Repository-Interfaces in der Domäne und implementieren Sie SQL im Infrastruktur-Layer. Injizieren Sie das Repository in den Use Case.

Fehler: Vermischung von Synchronisations- und Integrationsverhalten (z. B. Senden von E-Mails synchron in Transaktionen).

Korrektur: Entkoppeln Sie Nebenwirkungen über Events oder asynchrone Adapter. Use Cases erzeugen Domain Events; Infrastruktur verarbeitet diese ausserhalb kritischer Transaktionen.

Nutzen für KMU

Geringere Wartungskosten: Änderungen an UI oder DB brauchen selten Domänenänderungen.

Bessere Testbarkeit: Kernlogik lässt sich ohne Infrastruktur testen.

Planbare Migrationen: Austausch von Komponenten gelingt schrittweise.

14–30-Tage-Handlungsanleitung

Tag 1–3: Inventur bestehender Codebasen. Identifizieren Sie Domänenlogik, Use Cases, Controller und Infrastruktur. Markieren Sie Orte mit direktem Datenbankzugriff oder Geschäftsregeln in UI/Controller.

Tag 4–7: Modellieren Sie die Domäne in einem Workshop mit Fachabteilung. Erstellen Sie Entitäten und Use-Case-Listen in kurzer, klarer Form.

Tag 8–10: Definieren Sie Interfaces/Ports für Repository, Messaging und externe APIs. Legen Sie Namenskonventionen und Ordnerstruktur fest.

Tag 11–15: Refaktorieren Sie einen kritischen Use Case schrittweise: extrahieren Sie Geschäftslogik in Domänenklassen, ersetzen Sie direkte DB-Aufrufe durch Repository-Interfaces, schreiben Sie Unit-Tests.

Tag 16–20: Implementieren Sie Adapter für aktuelle Infrastruktur (z. B. SQL-Repository, SMTP-Adapter) und fügen Sie Integrationstests hinzu.

Tag 21–25: Überprüfen und automatisieren Sie Deployment-Pipeline für die neuen Module. Stellen Sie sicher, dass Konfigurationen getrennt sind.

Tag 26–30: Schulung für Entwickler: Prinzipien der Sauberen Architektur, Code-Reviews mit Fokus auf Schichtentrennung. Planen Sie für nächste Iteration: Weitere Use Cases refaktorieren.

Diese Schritte liefern sofortige Verbesserungen in Wartbarkeit und Flexibilität. Beginnen Sie mit einem wichtigen Use Case und iterieren Sie zielgerichtet. Saubere Architektur ist keine einmalige Änderung, sondern eine dauerhafte Praxis.