Webframeworkk/ASP.NET Core/Saubere Architektur - Versionsgeschichte

imported>Import: Version 206

2026-02-28T00:30:51Z

Version 206

Neue Seite

''Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).''
----

== 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 <code>CreatePerson</code>), 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 ===

<syntaxhighlight lang="csharp">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();
}</syntaxhighlight>
=== Application Layer ===

<syntaxhighlight lang="csharp">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();
}
}</syntaxhighlight>

-----

== 4. Vorteile der Clean Architecture ==

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

-----

== 5. Vergleich: Traditionell vs. Clean ==

{| class="wikitable"
|-
! 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.''

----
''Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).''

Thorsten: Die Seite wurde neu angelegt: „ == 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ängigk…“

2026-02-28T00:30:51Z

Die Seite wurde neu angelegt: „ == 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ängigk…“

← Nächstältere Version		Version vom 28. Februar 2026, 00:30 Uhr
Zeile 1:		Zeile 1:
	''Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).''		''Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).''
	----		----


	== 1. Einführung in die Clean Architecture ==		== 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.		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 ===		=== Kernprinzipien ===

	* '''Abhängigkeitsrichtung:''' Abhängigkeiten fließen immer von den äußeren Schichten zu den inneren Schichten ('''Core/Domain''').		* '''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.		* '''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.		* '''Unabhängigkeit:''' Die Geschäftslogik ist unabhängig von Frameworks, Datenbanken oder Benutzeroberflächen.

			----
	-----

	== 2. Die Schichten der Clean Architecture ==		== 2. Die Schichten der Clean Architecture ==

	=== 1. Domain Layer (Kernstück) ===		=== 1. Domain Layer (Kernstück) ===

	Dies ist das Herzstück Ihrer Anwendung. Es enthält die Business-Regeln und Domain-Modelle.		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.		* '''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.		* '''Abhängigkeiten:''' Keine. Der Domain-Layer ist vollkommen unabhängig.

	=== 2. Application Layer ===		=== 2. Application Layer ===

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

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

	=== 3. Infrastructure Layer ===		=== 3. Infrastructure Layer ===

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

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

	=== 4. Presentation Layer (UI) ===		=== 4. Presentation Layer (UI) ===

	Verarbeitet Benutzerinteraktionen und die Präsentationslogik.		Verarbeitet Benutzerinteraktionen und die Präsentationslogik.

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

			----
	-----

	== 3. Beispiel-Implementierung (Personen-Management) ==		== 3. Beispiel-Implementierung (Personen-Management) ==

	=== Domain Layer ===		=== Domain Layer ===
			<syntaxhighlight lang="csharp">
	<syntaxhighlight lang="csharp">public class Person		public class Person
	{		{
	public Guid PersonId { get; set; }		public Guid PersonId { get; set; }
Zeile 62:		Zeile 51:
	Task<Person> AddPerson(Person person);		Task<Person> AddPerson(Person person);
	Task<List<Person>> GetAllPersons();		Task<List<Person>> GetAllPersons();
	}</syntaxhighlight>		}
			</syntaxhighlight>

	=== Application Layer ===		=== Application Layer ===
			<syntaxhighlight lang="csharp">
	<syntaxhighlight lang="csharp">public interface IPersonsService		public interface IPersonsService
	{		{
	Task<PersonDto> CreatePerson(PersonDto personDto);		Task<PersonDto> CreatePerson(PersonDto personDto);
Zeile 86:		Zeile 77:
	return createdPerson.ToDto();		return createdPerson.ToDto();
	}		}
	}</syntaxhighlight>		}
			</syntaxhighlight>

	-----		----

	== 4. Vorteile der Clean Architecture ==		== 4. Vorteile der Clean Architecture ==
Zeile 97:		Zeile 89:
	# '''Skalierbarkeit:''' Die Architektur erlaubt ein einfaches Hoch- oder Ausrechnen der Anwendung.		# '''Skalierbarkeit:''' Die Architektur erlaubt ein einfaches Hoch- oder Ausrechnen der Anwendung.

			----

	~~-----~~		== 5. Vergleich: Traditionell vs. Clean ==

	== 5. Vergleich: Traditionell vs. ~~Clean~~ ==

	{\| class="wikitable"		{\| class="wikitable"
	\|-
	! Merkmal		! Merkmal
	! Traditionelle N-Tier		! Traditionelle N-Tier
Zeile 121:		Zeile 111:
	\|}		\|}

			----
	-----

	== 6. Interview Tipps ==		== 6. Interview Tipps ==

	* '''Erklären Sie die Schichten:''' Seien Sie bereit, den Zweck jeder Schicht und deren Interaktion zu beschreiben.		* '''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.		* '''Abhängigkeitsrichtung:''' Betonen Sie, dass Abhängigkeiten immer nach innen zum Domain-Layer fließen.
Zeile 131:		Zeile 119:
	* '''Trade-offs:''' Clean Architecture fügt Komplexität hinzu – überlegen Sie, ob sie für die Projektgröße angemessen ist.		* '''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.''		''Erstellt basierend auf der Textanalyse von text.txt.''

	----		----
	''Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).''		''Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).''