Schichtenarchitektur und Clean Architecture in C#

Wenn Softwareprojekte wachsen, wird es immer wichtiger, den Code organisiert und wartbar zu halten. Zu diesem Zweck werden die Schichtenarchitektur (Layered Architecture) und ihre moderne Weiterentwicklung, die Clean Architecture, verwendet. Beide Modelle bieten eine starke Grundlage, um Abhängigkeiten zu verwalten, Verantwortlichkeiten zu trennen und testbare, erweiterbare Systeme zu entwickeln.

Was ist eine Schichtenarchitektur?

Die Schichtenarchitektur ist ein klassisches Architekturmodell, das eine Anwendung in verschiedene Schichten mit unterschiedlichen Verantwortlichkeiten unterteilt. Die gängigste Form besteht aus 3 oder 4 Schichten:

• Presentation (UI) – Die Benutzerschnittstelle (z. B. Razor Pages, WPF, API Controller).
• Business (Service / Application) – Enthält die Geschäftslogik und Regeln.
• Data Access (Repository / Infrastructure) – Verwaltet den Zugriff auf Datenbanken oder externe Quellen.
• Core / Domain – Enthält Modelle, Entitäten und Schnittstellen (optionale Schicht).

Die Abhängigkeitsrichtung verläuft von oben nach unten: Die UI-Schicht kann auf Business zugreifen, Business auf Data Access, aber nicht umgekehrt.

Klassischer Ablauf der Schichtenarchitektur

Das folgende Diagramm zeigt ein einfaches Beispiel:

graph TD;
  A[UI-Schicht] --> B[Business-Schicht];
  B --> C[Data-Access-Schicht];
  C --> D[Datenbank];

Diese Struktur reicht für einfache CRUD-Systeme aus, kann aber mit der Zeit komplex werden, wenn die Schichten eng gekoppelt sind.

Was ist Clean Architecture?

Die Clean Architecture wurde von Robert C. Martin (Uncle Bob) entwickelt und richtet die Abhängigkeiten auf den Kern (Domain) aus. Ziel ist es, die Geschäftslogik vollständig von der Außenwelt zu isolieren.

Die Schichten sind nun von außen nach innen abhängig:

graph LR;
  A[UI / API] --> B[Application];
  B --> C[Domain];
  C --> D[Infrastructure (Extern)];

• Domain – Der Kern: Entitäten, Value Objects und Schnittstellen.
• Application – Use Cases, Services, Anwendungslogik.
• Infrastructure – Datenbank, Dateisystem, E-Mail- oder API-Integrationen.
• Presentation – API-, Web- oder Desktop-Benutzeroberfläche.

Der wichtigste Unterschied: Die Domain-Schicht hängt nie von äußeren Schichten ab.

Schichten und Verantwortlichkeiten in der Clean Architecture

• Domain: Der Kern der Anwendung. Hier werden Entity-, Value Object- und Interface-Typen definiert. Die Geschäftsregeln befinden sich in dieser Schicht.
• Application: Verwendet die Domain-Schnittstellen, um Geschäftsprozesse (Use Cases) zu steuern. Beispiele: „Bestellung erstellen“, „Zahlung freigeben“.
• Infrastructure: Implementiert die in der Application-Schicht definierten Schnittstellen. (z. B. EF Core, SMTP, Dateispeicherung, API-Aufrufe)
• Presentation: Die dem Benutzer am nächsten liegende Schicht (Web-API, MVC, WPF etc.).

Abhängigkeitsregel (Dependency Rule)

Das wichtigste Prinzip der Clean Architecture lautet: Abhängigkeiten zeigen immer nach innen. Äußere Schichten kennen die inneren, aber die inneren wissen nichts über die äußeren.

// Domain-Schicht (keine Abhängigkeiten)
public class Order
{
    public int Id { get; set; }
    public decimal Total { get; set; }
    public bool IsApproved { get; private set; }

    public void Approve()
    {
        if (Total <= 0)
            throw new InvalidOperationException("Der Betrag muss größer als 0 sein.");
        IsApproved = true;
    }
}

// Application-Schicht
public interface IOrderRepository
{
    Task<Order> GetByIdAsync(int id);
    Task SaveAsync(Order order);
}

public class ApproveOrderUseCase
{
    private readonly IOrderRepository _repository;
    public ApproveOrderUseCase(IOrderRepository repository)
        => _repository = repository;

    public async Task ExecuteAsync(int id)
    {
        var order = await _repository.GetByIdAsync(id);
        order.Approve();
        await _repository.SaveAsync(order);
    }
}

// Infrastructure-Schicht
public class EfOrderRepository : IOrderRepository
{
    private readonly AppDbContext _context;
    public EfOrderRepository(AppDbContext context) => _context = context;

    public Task<Order> GetByIdAsync(int id) =>
        _context.Orders.FirstOrDefaultAsync(o => o.Id == id);

    public Task SaveAsync(Order order)
    {
        _context.Update(order);
        return _context.SaveChangesAsync();
    }
}

// Presentation-Schicht (API)
[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    private readonly ApproveOrderUseCase _useCase;
    public OrdersController(ApproveOrderUseCase useCase) => _useCase = useCase;

    [HttpPost("{id}/approve")]
    public async Task Approve(int id)
    {
        await _useCase.ExecuteAsync(id);
        return Ok();
    }
}

Wie man sieht, kennt die Domain-Schicht keine Infrastruktur. Die Application-Schicht arbeitet nur mit Schnittstellen. Dadurch können Abhängigkeiten leicht ersetzt werden (z. B. EF Core durch Dapper).

Abhängigkeitsverwaltung zwischen den Schichten

Abhängigkeiten werden typischerweise über Dependency Injection (DI) in der Infrastructure- oder Composition Root-Schicht aufgelöst:

// Program.cs oder Startup.cs
builder.Services.AddScoped<IOrderRepository, EfOrderRepository>();
builder.Services.AddScoped<ApproveOrderUseCase>();

Der Controller kennt nur ApproveOrderUseCase und weiß nicht, welche Repository-Implementierung verwendet wird.

Unterschiede zwischen Schichten- und Clean Architecture

Praxisbeispiel: E-Commerce-Anwendung

Unten sehen Sie eine vereinfachte Struktur eines Clean Architecture-basierten E-Commerce-Systems:

• Domain: Entitäten und Schnittstellen wie Order, Product, Customer.
• Application: Use Cases wie „OrderService“ oder „PlaceOrderUseCase“.
• Infrastructure: EF Core-basiertes Repository „EfOrderRepository“.
• Presentation: ASP.NET Core Web API-Schicht.

Mit dieser Struktur kann die UI-Schicht (z. B. API vs. WPF) geändert werden, ohne dass die Geschäftslogik (Domain & Application) angepasst werden muss.

Best Practices

• Verwalten Sie Abhängigkeiten zwischen Schichten mit Interfaces.
• Die Domain-Schicht sollte keine externen NuGet-Pakete verwenden (nur .NET-Standard).
• Verwenden Sie Use Case-basierte Services (z. B. CreateOrderUseCase).
• Ihre Entitäten sollten Geschäftslogik enthalten, nicht nur Daten.
• Nutzen Sie Tools wie Mapster oder AutoMapper für DTO-/Modell-Mapping.
• Jede Schicht als separates Projekt (Assembly) zu organisieren ist eine gute Praxis.

Beispielhafte Projektstruktur

MyApp/
├── MyApp.Domain/
│   ├── Entities/
│   ├── Interfaces/
│   └── Exceptions/
├── MyApp.Application/
│   ├── UseCases/
│   ├── Services/
│   └── DTOs/
├── MyApp.Infrastructure/
│   ├── Persistence/
│   └── Repositories/
└── MyApp.API/
    ├── Controllers/
    └── Program.cs

Diese Struktur entspricht der Clean Architecture und bietet eine modulare, leicht wartbare .NET-Lösung.

TL;DR

Ähnliche Artikel