Yandrik/swa-dojo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: split large exercise blocks into smaller ones

Browse Source
This commit is contained in:
Yandrik
2025-07-10 13:01:53 +02:00
parent 8d39486d67
commit 4da8446f37
7 changed files with 148 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
data/swa_exercises.7.ts
View File

@ -3,8 +3,8 @@ import { Exercise } from '../types';
export const swaExercises7: Exercise[] = [
{
id: 'swa-7-1-ddd-tactical',
title: '6.1 - SWA - Domain-Driven Design (Tactical)',
id: 'swa-7-1-ddd-tactical-a',
title: '6.1 - SWA - Domain-Driven Design (Tactical Teil 1)',
parts: [
{
id: '6-1-a',
@ -33,7 +33,14 @@ export const swaExercises7: Exercise[] = [
solution: 'Domain Events sind Objekte, die ein wichtiges Geschäftsereignis repräsentieren (z.B. "OrderPlaced"). Sie ermöglichen eine lose, asynchrone Kommunikation zwischen Aggregaten. Ein Aggregat publiziert ein Event, und andere Aggregate können darauf reagieren, ohne dass eine direkte Kopplung entsteht. Dies wahrt die Transaktionsgrenzen der Aggregate und ermöglicht eine eventually consistent Architektur.',
points: 6,
type: 'text',
},
}
],
explanation: '### Lösungserklärung\n\n**Tactical Design** ist der Teil von DDD, der sich mit den konkreten Entwurfsmustern innerhalb eines Bounded Context befasst.\n\n- **Entities & Value Objects**: Die grundlegenden Bausteine. **Entities** haben eine ID, **Value Objects** nicht.\n- **Aggregate**: Eine Gruppe von Objekten, die eine **Konsistenzgrenze** bilden. Änderungen am Aggregat geschehen immer in einer einzigen Transaktion. Der **Aggregate Root** ist der einzige Einstiegspunkt und schützt die Geschäftsregeln (Invarianten) des Aggregats.\n- **Referenzen per ID**: Um Aggregate lose zu koppeln, verweisen sie aufeinander nur über IDs, nicht über direkte Objektreferenzen.\n- **Domain Events**: Werden für die **asynchrone Kommunikation** zwischen Aggregaten genutzt, um die lose Kopplung aufrechtzuerhalten.\n\n### Quellen\n*Folien 6.1, Seite 23-48*'
},
{
id: 'swa-7-1-ddd-tactical-b',
title: '6.1 - SWA - Domain-Driven Design (Tactical Teil 2)',
parts: [
{
id: '6-1-e',
prompt: 'Beschreiben Sie die vier Schichten der DDD-Layered-Architecture und deren Verantwortlichkeiten.',
@ -56,11 +63,11 @@ export const swaExercises7: Exercise[] = [
type: 'text',
}
],
explanation: '### Lösungserklärung\n\n**Tactical Design** ist der Teil von DDD, der sich mit den konkreten Entwurfsmustern innerhalb eines Bounded Context befasst.\n\n- **Entities & Value Objects**: Die grundlegenden Bausteine. **Entities** haben eine ID, **Value Objects** nicht.\n- **Aggregate**: Eine Gruppe von Objekten, die eine **Konsistenzgrenze** bilden. Änderungen am Aggregat geschehen immer in einer einzigen Transaktion. Der **Aggregate Root** ist der einzige Einstiegspunkt und schützt die Geschäftsregeln (Invarianten) des Aggregats.\n- **Referenzen per ID**: Um Aggregate lose zu koppeln, verweisen sie aufeinander nur über IDs, nicht über direkte Objektreferenzen.\n- **Domain Events**: Werden für die **asynchrone Kommunikation** zwischen Aggregaten genutzt, um die lose Kopplung aufrechtzuerhalten.\n- **Layered Architecture**: Die klassische DDD-Architektur trennt UI, Application, Domain und Infrastructure. Die Abhängigkeiten zeigen immer nach innen zur Domain.\n- **Repository**: Abstrahiert den Datenbankzugriff für ein Aggregat. Die Schnittstelle gehört zur Domäne, die Implementierung zur Infrastruktur.\n- **Anemic Domain Model**: Ein Anti-Pattern, bei dem Objekte nur Datenhalter sind und die Logik in Services ausgelagert wird. Dies widerspricht dem DDD-Ziel, Daten und Verhalten zu kapseln.\n\n### Quellen\n*Folien 6.1, Seite 23-48*'
explanation: '### Lösungserklärung\n\n- **Layered Architecture**: Die klassische DDD-Architektur trennt UI, Application, Domain und Infrastructure. Die Abhängigkeiten zeigen immer nach innen zur Domain.\n- **Repository**: Abstrahiert den Datenbankzugriff für ein Aggregat. Die Schnittstelle gehört zur Domäne, die Implementierung zur Infrastruktur.\n- **Anemic Domain Model**: Ein Anti-Pattern, bei dem Objekte nur Datenhalter sind und die Logik in Services ausgelagert wird. Dies widerspricht dem DDD-Ziel, Daten und Verhalten zu kapseln.\n\n### Quellen\n*Folien 6.1, Seite 23-48*'
},
{
id: 'swa-7-1-heuristiken',
title: '7.1 - SWA - Heuristiken',
id: 'swa-7-1-heuristiken-a',
title: '7.1 - SWA - Heuristiken (Teil 1)',
parts: [
{
id: '7-1-a',
@ -89,7 +96,14 @@ export const swaExercises7: Exercise[] = [
solution: 'OCP: Software-Einheiten sollen offen für Erweiterungen, aber geschlossen für Modifikationen sein. Man fügt neues Verhalten hinzu, ohne bestehenden Code zu ändern (z.B. durch Interfaces).\nLSP: Unterklassen müssen ihre Oberklassen jederzeit ersetzen können, ohne das Programmverhalten zu ändern. "is-a"-Beziehung.',
points: 6,
type: 'text',
},
}
],
explanation: '### Lösungserklärung\n\n**Heuristiken** sind bewährte "Faustregeln", die Architekten helfen, gute Designentscheidungen zu treffen.\n\n- **Low Coupling & High Cohesion**: Das wichtigste Duo. **Hohe Kohäsion** innerhalb einer Komponente (alles darin gehört zusammen), **lose Kopplung** zwischen den Komponenten (sie sind möglichst unabhängig voneinander).\n- **SOLID-Prinzipien** sind eine Sammlung von fünf zentralen Heuristiken:\n - **S**ingle Responsibility Principle (SRP): Eine Klasse, eine Aufgabe.\n - **O**pen-Closed Principle (OCP): Erweiterbar, ohne den Code zu ändern.\n - **L**iskov Substitution Principle (LSP): Unterklassen müssen ihre Oberklassen vollständig ersetzen können.\n\n### Quellen\n*Folien 7.1, Seite 3-37*'
},
{
id: 'swa-7-1-heuristiken-b',
title: '7.1 - SWA - Heuristiken (Teil 2)',
parts: [
{
id: '7-1-e',
prompt: 'Erläutern Sie das "Interface Segregation Principle" (ISP) und das "Dependency Inversion Principle" (DIP).',
@ -104,7 +118,7 @@ export const swaExercises7: Exercise[] = [
points: 5,
type: 'text',
},
{
{
id: '7-1-g',
prompt: 'Was ist das „God-Object"-Antipattern und welche Heuristik verletzt es primär?',
solution: 'Ein God-Object ist ein Anti-Pattern, bei dem eine einzelne Klasse oder Komponente zu viele, nicht zusammengehörende Verantwortlichkeiten übernimmt. Sie wird riesig und ist schwer zu warten und zu testen.\n\nEs verletzt primär das "Single Responsibility Principle" (bzw. die Heuristik der "Separation of Concerns" und "High Cohesion").',
@ -117,8 +131,8 @@ export const swaExercises7: Exercise[] = [
solution: 'AT-Software (Application + Technology) ist Software, die Fachlogik (A) und technische Belange (T) stark vermischt. Dies sollte vermieden werden, weil es zu hoher Kopplung führt, die Wartbarkeit erschwert und die Wiederverwendbarkeit praktisch unmöglich macht. Fachliche Änderungen wirken sich auf technische Teile aus und umgekehrt.',
points: 5,
type: 'text',
},
}
],
explanation: '### Lösungserklärung\n\n**Heuristiken** sind bewährte "Faustregeln", die Architekten helfen, gute Designentscheidungen zu treffen.\n\n- **Low Coupling & High Cohesion**: Das wichtigste Duo. **Hohe Kohäsion** innerhalb einer Komponente (alles darin gehört zusammen), **lose Kopplung** zwischen den Komponenten (sie sind möglichst unabhängig voneinander).\n- **SOLID-Prinzipien** sind eine Sammlung von fünf zentralen Heuristiken:\n - **S**ingle Responsibility Principle (SRP): Eine Klasse, eine Aufgabe.\n - **O**pen-Closed Principle (OCP): Erweiterbar, ohne den Code zu ändern.\n - **L**iskov Substitution Principle (LSP): Unterklassen müssen ihre Oberklassen vollständig ersetzen können.\n - **I**nterface Segregation Principle (ISP): Lieber viele kleine, spezifische Interfaces als ein großes.\n - **D**ependency Inversion Principle (DIP): Abhängigkeiten sollten auf Abstraktionen (Interfaces) zeigen, nicht auf konkrete Implementierungen.\n- **Weitere wichtige Heuristiken**: **DRY** (vermeide Redundanz), **KISS** (halte es einfach) und **Information Hiding** (verberge Implementierungsdetails).\n\nDas **God-Object**-Antipattern ist ein klassisches Beispiel für die Verletzung des **SRP** und der **hohen Kohäsion**. Es ist eine Klasse, die zu viele Verantwortungen an sich reißt, was zu einem schwer wartbaren System führt. Ähnlich problematisch ist **AT-Software**, die Fach- und Technik-Code vermischt.\n\n### Quellen\n*Folien 7.1, Seite 3-37*'
explanation: '### Lösungserklärung\n\n- **SOLID-Prinzipien** (fortgesetzt):\n - **I**nterface Segregation Principle (ISP): Lieber viele kleine, spezifische Interfaces als ein großes.\n - **D**ependency Inversion Principle (DIP): Abhängigkeiten sollten auf Abstraktionen (Interfaces) zeigen, nicht auf konkrete Implementierungen.\n- **Weitere wichtige Heuristiken**: **DRY** (vermeide Redundanz), **KISS** (halte es einfach) und **Information Hiding** (verberge Implementierungsdetails).\n\nDas **God-Object**-Antipattern ist ein klassisches Beispiel für die Verletzung des **SRP** und der **hohen Kohäsion**. Es ist eine Klasse, die zu viele Verantwortungen an sich reißt, was zu einem schwer wartbaren System führt. Ähnlich problematisch ist **AT-Software**, die Fach- und Technik-Code vermischt.\n\n### Quellen\n*Folien 7.1, Seite 3-37*'
}
];