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.3.ts
View File

@ -3,8 +3,8 @@ import { Exercise } from '../types';
export const swaExercises3: Exercise[] = [
{
id: 'swa-3-1-backend',
title: '3.1 - SWA - Technische Architektur Backend',
id: 'swa-3-1-backend-a',
title: '3.1 - SWA - Technische Architektur Backend (Teil 1)',
parts: [
{
id: '3-1-a',
@ -33,8 +33,15 @@ export const swaExercises3: Exercise[] = [
solution: '```mermaid\ngraph TD\n A[Facade Layer] --> B[Logic Layer]\n B --> C[Data Access Layer]\n```',
points: 4,
type: 'mermaid'
},
{
}
],
explanation: '### Lösungserklärung\n\n**Aufgaben des Backends**: Das Backend führt die Kernlogik aus, verwaltet Daten und stellt Funktionalität über APIs bereit.\n\n**Fehlerverhalten**: **Spezifizierte Fehler** (z.B. "Benutzer nicht gefunden") sind Teil des API-Vertrags. **Unspezifizierte Fehler** (Bugs) dürfen nie direkt zum Client durchdringen. Eine **Sicherheitsfacade** fängt sie ab und gibt eine generische Meldung zurück.\n\n**Architekturmuster**:\n- **Traditionelle Schichtenarchitektur**: Strikte Top-Down-Abhängigkeiten (UI → Logik → Daten). Einfach zu verstehen, aber oft starr.\n\n### Quellen\n*Folien 3.1, Seite 4-27*'
},
{
id: 'swa-3-1-backend-b',
title: '3.1 - SWA - Technische Architektur Backend (Teil 2)',
parts: [
{
id: '3-1-e',
prompt: 'Zeichnen Sie die typische Schichten-Architektur eines Backends nach der Use Case Driven Schichtenarchitektur.',
solution: '```mermaid\ngraph TD\n A[Service-Schicht] --> B[Use Case-Schicht]\n B --> C[DAO-Schicht]\n C --> D[Entity-Schicht]\n```',
@ -55,7 +62,7 @@ export const swaExercises3: Exercise[] = [
points: 6,
type: 'text',
},
{
{
id: '3-1-h',
prompt: 'Wozu dient ein DTO und was bedeutet die Abkürzung? Geben Sie außerdem ein Beispiel an für einen Use Case "Bestellung anzeigen".',
solution: 'DTO steht für Data Transfer Object. Es ist ein reiner Datencontainer für den Datentransfer zwischen Schichten oder Systemen, um Entkopplung zu schaffen.\nBeispiel für `OrderDetailsDTO`:\n```json\n{\n "orderId": "O-123",\n "customerName": "Max Mustermann",\n "orderDate": "2023-10-27",\n "totalAmount": 99.98,\n "items": [\n { "productId": "P-456", "productName": "Laptop", "quantity": 1, "unitPrice": 99.98 }\n ]\n}\n```',
@ -63,11 +70,11 @@ export const swaExercises3: Exercise[] = [
type: 'text',
}
],
explanation: '### Lösungserklärung\n\n**Aufgaben des Backends**: Das Backend führt die Kernlogik aus, verwaltet Daten und stellt Funktionalität über APIs bereit.\n\n**Fehlerverhalten**: **Spezifizierte Fehler** (z.B. "Benutzer nicht gefunden") sind Teil des API-Vertrags. **Unspezifizierte Fehler** (Bugs) dürfen nie direkt zum Client durchdringen. Eine **Sicherheitsfacade** fängt sie ab und gibt eine generische Meldung zurück.\n\n**Architekturmuster**:\n- **Traditionelle Schichtenarchitektur**: Strikte Top-Down-Abhängigkeiten (UI → Logik → Daten). Einfach zu verstehen, aber oft starr.\n- **Use Case Driven Architektur**: Eine Variante, die die Logik-Schicht in spezifische Anwendungsfälle (Use Cases) unterteilt.\n- **Hexagonale Architektur** (Ports & Adapters): Kehrt die Abhängigkeiten um. Äußere Adapter (UI, DB) hängen vom Kern (Logik) ab. Der Kern bleibt unabhängig von der Technologie, was die Austauschbarkeit und Testbarkeit massiv verbessert.\n\n**Data Transfer Object (DTO)**: Ein DTO ist ein Objekt nur zum Transport von Daten. Es entkoppelt die Schnittstelle von der internen Implementierung (z.B. Datenbank-Entities). Dies macht die Architektur flexibler und robuster gegenüber Änderungen.\n\n### Quellen\n*Folien 3.1, Seite 4-27*'
explanation: '### Lösungserklärung\n\n**Architekturmuster**:\n- **Use Case Driven Architektur**: Eine Variante, die die Logik-Schicht in spezifische Anwendungsfälle (Use Cases) unterteilt.\n- **Hexagonale Architektur** (Ports & Adapters): Kehrt die Abhängigkeiten um. Äußere Adapter (UI, DB) hängen vom Kern (Logik) ab. Der Kern bleibt unabhängig von der Technologie, was die Austauschbarkeit und Testbarkeit massiv verbessert.\n\n**Data Transfer Object (DTO)**: Ein DTO ist ein Objekt nur zum Transport von Daten. Es entkoppelt die Schnittstelle von der internen Implementierung (z.B. Datenbank-Entities). Dies macht die Architektur flexibler und robuster gegenüber Änderungen.\n\n### Quellen\n*Folien 3.1, Seite 4-27*'
},
{
id: 'swa-3-3-integration',
title: '3.3 - SWA – Integrationstechnologien',
id: 'swa-3-3-integration-a',
title: '3.3 - SWA – Integrationstechnologien (Teil 1)',
parts: [
{
id: '3-3-a',
@ -96,7 +103,14 @@ export const swaExercises3: Exercise[] = [
solution: 'EDA (Event Driven Architecture) ist ein Architekturmuster, bei dem die Kommunikation und der Ablauf durch Ereignisse (Events) gesteuert werden. Komponenten (Producer, Consumer) sind lose über einen Event-Broker gekoppelt und kommunizieren asynchron. Dies fördert Skalierbarkeit und Resilienz.',
points: 5,
type: 'text',
},
}
],
explanation: '### Lösungserklärung\n\n**Integrationsmuster**: **Synchron** (z.B. REST-Aufruf) bedeutet, der Aufrufer wartet auf eine Antwort. **Asynchron** (z.B. Messaging) bedeutet, der Sender schickt eine Nachricht und wartet nicht.\n\n**REST**: Ein Architekturstil, der HTTP-Methoden für CRUD-Operationen auf Ressourcen nutzt. Die URL-Struktur (`/customers/{id}`) identifiziert die Ressource, die Methode (`GET`, `POST`, etc.) die Operation.\n\n**EDA (Event Driven Architecture)**: Ein Paradigma, das auf asynchroner Kommunikation durch **Events** basiert. Es führt zu extrem loser Kopplung und ist die Grundlage für viele moderne Microservice-Systeme.\n\n### Quellen\n*Folien 3.3, Seite 5-42*'
},
{
id: 'swa-3-3-integration-b',
title: '3.3 - SWA – Integrationstechnologien (Teil 2)',
parts: [
{
id: '3-3-e',
prompt: 'Wozu dient das Protokoll AMQP und was sind seine Vorteile?',
@ -119,6 +133,6 @@ export const swaExercises3: Exercise[] = [
type: 'text',
},
],
explanation: '### Lösungserklärung\n\n**Integrationsmuster**: **Synchron** (z.B. REST-Aufruf) bedeutet, der Aufrufer wartet auf eine Antwort. **Asynchron** (z.B. Messaging) bedeutet, der Sender schickt eine Nachricht und wartet nicht.\n\n**REST**: Ein Architekturstil, der HTTP-Methoden für CRUD-Operationen auf Ressourcen nutzt. Die URL-Struktur (`/customers/{id}`) identifiziert die Ressource, die Methode (`GET`, `POST`, etc.) die Operation.\n\n**EDA (Event Driven Architecture)**: Ein Paradigma, das auf asynchroner Kommunikation durch **Events** basiert. Es führt zu extrem loser Kopplung und ist die Grundlage für viele moderne Microservice-Systeme.\n\n**AMQP**: Ein standardisiertes Protokoll für asynchrones Messaging, das von Brokern wie RabbitMQ implementiert wird. Es sorgt für Interoperabilität und zuverlässige Nachrichtenübermittlung.\n\n**Komplexität der Integration**: Die Herausforderung liegt oft im Detail: unterschiedliche Datenmodelle, die gemappt werden müssen; komplexe Fehlerbehandlungsstrategien für den Fall, dass ein System nicht erreichbar ist; und die Gewährleistung von Datenkonsistenz über verteilte Systeme hinweg.\n\n### Quellen\n*Folien 3.3, Seite 5-42*'
explanation: '### Lösungserklärung\n\n**AMQP**: Ein standardisiertes Protokoll für asynchrones Messaging, das von Brokern wie RabbitMQ implementiert wird. Es sorgt für Interoperabilität und zuverlässige Nachrichtenübermittlung.\n\n**Komplexität der Integration**: Die Herausforderung liegt oft im Detail: unterschiedliche Datenmodelle, die gemappt werden müssen; komplexe Fehlerbehandlungsstrategien für den Fall, dass ein System nicht erreichbar ist; und die Gewährleistung von Datenkonsistenz über verteilte Systeme hinweg.\n\n### Quellen\n*Folien 3.3, Seite 5-42*'
}
];