Clean Architecture in .NET: Warum sie in Enterprise-Projekten standält
Clean Architecture in .NET ist kein Selbstzweck. Der Beitrag zeigt, wie Teams Abhängigkeiten sauber trennen und so schneller liefern, testen und weiterentwickeln können.
In meiner Arbeit als Softwarearchitekt begegne ich regelmäßig Projekten, die irgendwann an ihre eigene Komplexität stoßen: Tests, die niemand mehr schreibt, weil die Abhängigkeiten zu verschachtelt sind. Deployments, die gefürchtet werden. Features, die zwei Wochen daürn, obwohl sie eigentlich trivial klingen.
Fast immer liegt die Ursache nicht im fehlendem Können des Teams, sondern in einer Architektur, die mit den Anforderungen gewachsen ist - aber ohne klare Struktur.
Clean Architecture ist ein bewährter Ansatz, dieses Problem von Anfang an zu vermeiden. Ich möchte erklären, wie ich ihn in .NET-Projekten einsetze und was dabei wirklich wichtig ist.
Weiterführende Artikel zu diesem Thema: Arc42 Adrs Architekturentscheidungen und Integrationen Mit Dynamics 365 Und Dotnet.
Was ist Clean Architecture?
Der Begriff stammt von Robert C. Martin (“Uncle Bob”) und beschreibt ein Schichtenmodell, bei dem Abhängigkeiten immer nach innen zeigen - in Richtung Domäne, nie nach außen zu Frameworks oder Datenbanken.
Das Kernprinzip: Ihr Geschäftscode sollte nicht wissen, ob dahinter eine PostgreSQL-Datenbank, ein REST-API oder ein ganz anderes System steckt.
In der Praxis ergibt sich eine klare Trennung:
Die vier Schichten
Domain - Das Herzstück. Hier leben Ihre Entitäten, Wertobjekte und Domänenlogik. Keine Abhängigkeit nach außen. In .NET typischerweise ein reines Class Library-Projekt ohne NuGet-Pakete außer vielleicht FluentValidation für Validierungsregeln.
Application - Orchestriert die Domänenlogik. Hier finden sich Use Cases (oder Commands/Queries bei CQRS), Interfaces für externe Services und Application-spezifische DTOs. Die Application-Schicht kennt die Domäne, aber nicht die Infrastruktur.
Infrastructure - Implementiert die Interfaces aus der Application-Schicht: Datenbankzugriff via Entity Framework, HTTP-Clients für externe APIs, E-Mail-Versand. Diese Schicht kann ausgetauscht werden, ohne die Geschäftslogik zu berühren.
Presentation - Die Eintrittspunkte: ASP.NET Core Controller, Blazor-Komponenten, Background Services. Ihre Aufgabe: Reqüsts entgegennehmen, an die Application-Schicht delegieren, Responses zurückgeben.
Warum das in Enterprise-Projekten entscheidend ist
Bei kleineren Projekten fühlt sich Clean Architecture manchmal wie Overengineering an. Bei Projekten, die über Jahre wachsen und von mehreren Teams gepflegt werden, ist sie unverzichtbar - aus drei Gründen:
Testbarkeit. Da die Domänen- und Application-Schicht keine äußeren Abhängigkeiten kennen, lassen sie sich vollständig mit Unit Tests abdecken - ohne Datenbank, ohne HTTP-Requests. In einem Projekt, an dem ich gearbeitet habe, konnten wir dank dieser Trennung über 85 % der Geschäftslogik mit xUnit, FakeItEasy und AutoFixture testen, in Millisekunden, ohne externe Abhängigkeiten.
Wartbarkeit. Wenn ein neüs Teammitglied einen Bug in der Rechnungslogik sucht, findet es ihn in der Domain- oder Application-Schicht - nicht zwischen Controller-Code und Entity Framework-Abfragen vermischt.
Austauschbarkeit. Ich habe selbst eine Migration von Aurea CRM zu Microsoft Dynamics 365 begleitet. Der Migrations-Code war ein .NET-Tool, das über klar definierte Interfaces mit beiden Systemen kommunizierte. Die eigentliche Transformationslogik musste nie angefasst werden - nur die Infrastructure-Implementierungen wurden ausgetauscht.
Ein konkretes Beispiel: Policy-Verwaltung
In einem Open-Source-Projekt für die Automobilindustrie haben wir einen Policy Hub entwickelt, über den Unternehmen ihre Datenaustausch-Richtlinien verwalten. Die Anforderungen änderten sich regelmäßig - Policies mussten validiert, versioniert und über REST-APIs bereitgestellt werden.
Weil die Kernlogik (Validierungsregeln, Statusübergänge) in der Domänenschicht lebte und über klar definierte Application-Layer-Interfaces mit der Außenwelt kommunizierte, konnten wir:
- Neü Validierungsregeln hinzufügen, ohne die API-Schicht anzufassen
- Integration Tests schreiben, die echte Datenbank-Szenarien abdeckten, ohne die Domänenlogik zu duplizieren
- Mehrere Teams parallel an verschiedenen Features arbeiten lassen, ohne ständige Merge-Konflikte
Die häufigsten Fehler
Anemic Domain Model. Entitäten haben nur Properties, keine Methoden. Die Logik wandert in Services - und plötzlich gibt es keine klare Domänenschicht mehr, sondern eine Sammlung von Utility-Klassen.
Schichten umgehen. “Das ist nur eine Kleinigkeit” - und schon greift ein Controller direkt auf den DbContext zu. Einmal etabliert, wird dieses Muster kopiert. Nach einem Jahr ist die Architektur ausgehöhlt.
Zu viele Abstraktionen. Das Gegenteil: Ein Repository-Interface für jede Entität, ein Service-Interface für jede Klasse. Das macht den Code schwerer lesbar, ohne echten Mehrwert. Abstrahieren Sie dort, wo es Testbarkeit oder Austauschbarkeit bringt - nicht überall.
Fehlende Arc42-Dokumentation. Architekturentscheidungen, die nicht dokumentiert sind, werden nach sechs Monaten vergessen - oder schlimmer, von Neuankömmlinge missverstanden und umgangen. Ich halte es für Best Practice, die wesentlichen ADRs (Architecture Decision Records) im Repo zu pflegen.
Fazit
Clean Architecture ist kein Selbstzweck. Sie ist ein Werkzeug, das Ihrem Team ermöglicht, schnell und sicher zu liefern - auch wenn das Projekt komplexer wird, das Team wächst oder Anforderungen sich ändern.
Der Einstieg lohnt sich schon bei mittelgroßen .NET-Projekten. Wenn Sie ein bestehendes Projekt schrittweise migrieren wollen: Beginnen Sie mit den Tests. Sobald Sie die Geschäftslogik isolieren können, haben Sie die schwierigste Arbeit schon getan.
Haben Sie Fragen zur Architektur Ihres nächsten Projekts? Sprechen Sie uns an - wir helfen gerne bei der Konzeption.
Weiterführende Beiträge
Wenn dieses Thema für Ihre Roadmap relevant ist, sind diese Beiträge der nächste sinnvolle Schritt: