Webframeworkk/ASP.NET Core/Saubere Architektur

1. Einführung in die Clean Architecture

Clean Architecture (auch bekannt als Onion Architecture) ist ein Softwaredesign-Prinzip, das auf Separation of Concerns (Trennung von Belangen), Testbarkeit und Wartbarkeit setzt. Die Anwendung wird in Schichten organisiert, wobei jede Schicht eine spezifische Verantwortung trägt und die Abhängigkeiten klar definiert sind.

Kernprinzipien

• Abhängigkeitsrichtung: Abhängigkeiten fließen immer von den äußeren Schichten zu den inneren Schichten (Core/Domain).
• Abstraktion: Äußere Schichten hängen von Abstraktionen (Interfaces) ab, die in den inneren Schichten definiert sind.
• Unabhängigkeit: Die Geschäftslogik ist unabhängig von Frameworks, Datenbanken oder Benutzeroberflächen.

2. Die Schichten der Clean Architecture

1. Domain Layer (Kernstück)

Dies ist das Herzstück Ihrer Anwendung. Es enthält die Business-Regeln und Domain-Modelle.

• Inhalt: Entities (z. B. Person, Product), Value Objects (z. B. Money, Address), Domain Services und Repository-Interfaces.
• Abhängigkeiten: Keine. Der Domain-Layer ist vollkommen unabhängig.

2. Application Layer

Dieser Layer orchestriert die Anwendungsfälle (Use Cases).

• Inhalt: Application Services (Use Cases like CreatePerson), DTOs (Data Transfer Objects) und Interfaces für Infrastruktur-Dienste.
• Abhängigkeiten: Hängt nur vom Domain Layer ab.

3. Infrastructure Layer

Implementiert die technischen Details für die Interaktion mit externen Systemen.

• Inhalt: Repositories (Datenbankzugriff), Implementierungen von externen Diensten (E-Mail, Dateisystem).
• Abhängigkeiten: Hängt vom Application Layer ab.

4. Presentation Layer (UI)

Verarbeitet Benutzerinteraktionen und die Präsentationslogik.

• Inhalt: Controller, Views und ViewModels.
• Abhängigkeiten: Hängt vom Application Layer ab.

3. Beispiel-Implementierung (Personen-Management)

Domain Layer

public class Person 
{
    public Guid PersonId { get; set; }
    public string Name { get; set; }
}

public interface IPersonsRepository 
{
    Task<Person> AddPerson(Person person);
    Task<List<Person>> GetAllPersons();
}

Application Layer

public interface IPersonsService 
{
    Task<PersonDto> CreatePerson(PersonDto personDto);
    Task<List<PersonDto>> GetAllPersons();
}

public class PersonsService : IPersonsService
{
    private readonly IPersonsRepository _personsRepository;

    public PersonsService(IPersonsRepository personsRepository)
    {
        _personsRepository = personsRepository;
    }

    public async Task<PersonDto> CreatePerson(PersonDto personDto)
    {
        var person = new Person { Name = personDto.Name }; // Mapping
        var createdPerson = await _personsRepository.AddPerson(person);
        return createdPerson.ToDto();
    }
}

4. Vorteile der Clean Architecture

1. Verbesserte Wartbarkeit: Änderungen sind auf spezifische Schichten isoliert.
2. Testbarkeit: Jede Schicht kann isoliert mit Mocks oder Stubs getestet werden.
3. Flexibilität: Externe Systeme (Datenbanken, APIs) können ausgetauscht werden, ohne den Kern zu beeinflussen.
4. Skalierbarkeit: Die Architektur erlaubt ein einfaches Hoch- oder Ausrechnen der Anwendung.

5. Vergleich: Traditionell vs. Clean

| Merkmal | Traditionelle N-Tier | Clean Architecture | |------------------|---------------------------------|---------------------------------------| | Zentrum | Datenbank / Datenzugriff | Domain / Business Logik | | Abhängigkeit | Logik hängt von Datenzugriff ab | Datenzugriff hängt von Logik ab (DIP) | | Testbarkeit | Schwierig (oft DB nötig) | Sehr hoch durch Mocking |

6. Interview Tipps

• Erklären Sie die Schichten: Seien Sie bereit, den Zweck jeder Schicht und deren Interaktion zu beschreiben.
• Abhängigkeitsrichtung: Betonen Sie, dass Abhängigkeiten immer nach innen zum Domain-Layer fließen.
• Abstraktionen: Erklären Sie die Bedeutung von Interfaces für die lose Kopplung.
• Trade-offs: Clean Architecture fügt Komplexität hinzu – überlegen Sie, ob sie für die Projektgröße angemessen ist.

Erstellt basierend auf der Textanalyse von text.txt.