From 4da8446f37fd4b31bae3abe4fe4a4980f5e45b58 Mon Sep 17 00:00:00 2001 From: Yandrik Date: Thu, 10 Jul 2025 13:01:53 +0200 Subject: [PATCH] feat: split large exercise blocks into smaller ones --- data/swa_exercises.1.ts | 42 ++++++++++++++++++++++++++++++----------- data/swa_exercises.2.ts | 29 ++++++++++++++++++++-------- data/swa_exercises.3.ts | 34 +++++++++++++++++++++++---------- data/swa_exercises.4.ts | 17 ++++++++++++----- data/swa_exercises.5.ts | 25 +++++++++++++++--------- data/swa_exercises.6.ts | 26 +++++++++++++++++++------ data/swa_exercises.7.ts | 34 +++++++++++++++++++++++---------- 7 files changed, 148 insertions(+), 59 deletions(-) diff --git a/data/swa_exercises.1.ts b/data/swa_exercises.1.ts index 9578ac0..cb6821e 100644 --- a/data/swa_exercises.1.ts +++ b/data/swa_exercises.1.ts @@ -1,10 +1,9 @@ - import { Exercise } from '../types'; export const swaExercises1: Exercise[] = [ { - id: 'swa-1-1-einfuehrung', - title: '1.1 - SWA - Einführung', + id: 'swa-1-1-einfuehrung-a', + title: '1.1 - SWA - Einführung (Teil 1)', parts: [ { id: '1-1-a', @@ -20,7 +19,7 @@ export const swaExercises1: Exercise[] = [ points: 4, type: 'text', }, - { + { id: '1-1-c', prompt: 'Wozu dienen Sichten in der Softwarearchitektur?', solution: 'Sichten beleuchten unterschiedliche Aspekte der Architektur. Sie dienen dazu:\n- Zuständigkeiten zu trennen (z.B. Entwickler vs. Betreiber).\n- Die Architektur aus unterschiedlichen Perspektiven zu zeigen (z.B. statische Struktur vs. dynamisches Verhalten).\n- Für unterschiedliche Stakeholder verständlich zu sein.', @@ -34,6 +33,13 @@ export const swaExercises1: Exercise[] = [ points: 4, type: 'text', }, + ], + explanation: '### Lösungserklärung\n\n**Softwarearchitektur** ist die grundlegende Organisation eines Systems. Sie definiert die Bausteine, deren Beziehungen und die Prinzipien, die den Entwurf leiten. Zur Kommunikation werden verschiedene **Sichten** (Perspektiven) verwendet.\n\n**Ziele & Aufgaben** ist es, **Leitplanken** für Entwickler zu bieten, um Komplexität zu managen und ein gemeinsames Verständnis zu schaffen.\n\n**Architekturerosion**: Wenn die Architektur nicht aktiv gepflegt wird, verfällt die Struktur. Dies führt zum Aufbau technischer Schulden, die zukünftige Änderungen erschweren.\n\n### Quellen\n*Folien 1.1, Seite 22-66*' + }, + { + id: 'swa-1-1-einfuehrung-b', + title: '1.1 - SWA - Einführung (Teil 2)', + parts: [ { id: '1-1-e', prompt: 'Erläutere das Big-ball-of-Mud Antipattern.', @@ -55,13 +61,20 @@ export const swaExercises1: Exercise[] = [ points: 4, type: 'text', }, - { + { id: '1-1-h', prompt: 'Wie kommt man zu einer „guten" Architektur?', solution: 'Man erreicht eine gute Architektur durch einen methodischen Prozess:\n- Verständnis erlangen (Anforderungen, Randbedingungen, Risiken)\n- Entwurf: Strukturen schaffen (Bausteine, Ablauf), fachlich beginnen und technisch verfeinern\n- Konzepte für technische Querschnittsthemen entwickeln (Persistenz, UI, etc.)\n- Bedarfsgerechte, kontinuierliche Kommunikation und Dokumentation\nEs gibt keine "Silberkugel", sondern man verwendet Methoden und Heuristiken.', points: 5, type: 'text', }, + ], + explanation: '### Lösungserklärung\n\n**Architekturerosion & Technische Schulden**: Ein Endzustand der Architekturerosion ist der **"Big Ball of Mud"**, ein System ohne erkennbare Struktur. **Symptome** dafür sind Starrheit, Zerbrechlichkeit, Unbeweglichkeit und Zähigkeit. Ein **guter Architekturprozess** ist methodisch und iterativ, um dem entgegenzuwirken.\n\n### Quellen\n*Folien 1.1, Seite 22-66*' + }, + { + id: 'swa-1-1-einfuehrung-c', + title: '1.1 - SWA - Einführung (Teil 3)', + parts: [ { id: '1-1-i', prompt: 'Wie funktioniert Architektur im agilen vs. klassischen Software-Entwicklungsprozess?', @@ -69,7 +82,7 @@ export const swaExercises1: Exercise[] = [ points: 5, type: 'text', }, - { + { id: '1-1-j', prompt: 'Erläutere das LRM = Least Reasonable Moment – Prinzip und wie es in agilen Projekten helfen kann. Nenne ein konkretes Beispiel.', solution: 'Das LRM (Least Reasonable Moment) ist ein Prinzip aus der Lean-Software-Entwicklung, das besagt, dass wichtige architektonische Entscheidungen so spät wie möglich getroffen werden sollten, um:\n- Mehr Informationen zu sammeln\n- Unsicherheiten zu reduzieren\n- Flexibilität zu bewahren\n\nBeispiel: Bei einem neuen E-Commerce-System muss das Team zwischen relationalen und NoSQL-Datenbanken wählen. Durch Warten auf den LRM können sie mehr Informationen über Datenmodelle und Leistungsanforderungen sammeln, bevor sie eine endgültige Entscheidung treffen.', @@ -91,11 +104,11 @@ export const swaExercises1: Exercise[] = [ type: 'text', } ], - explanation: '### Lösungserklärung\n\n**Softwarearchitektur** ist die grundlegende Organisation eines Systems. Sie definiert die Bausteine, deren Beziehungen und die Prinzipien, die den Entwurf leiten. Zur Kommunikation werden verschiedene **Sichten** (Perspektiven) verwendet.\n\n**Ziele & Aufgaben** ist es, **Leitplanken** für Entwickler zu bieten, um Komplexität zu managen und ein gemeinsames Verständnis zu schaffen. Ein **guter Architekturprozess** ist methodisch und iterativ.\n\n**Architekturerosion & Technische Schulden**: Wenn die Architektur nicht aktiv gepflegt wird, verfällt die Struktur (**Erosion**). Dies führt zum Aufbau **technischer Schulden**, die zukünftige Änderungen erschweren und verteuern. Ein Endzustand davon ist der **"Big Ball of Mud"**, ein System ohne erkennbare Struktur. **Symptome** dafür sind Starrheit, Zerbrechlichkeit, Unbeweglichkeit und Zähigkeit.\n\n**Prozesse**: Im **klassischen** Vorgehen wird die Architektur vorab detailliert geplant (**Big Design Up Front**). Im **agilen** Prozess entsteht sie **evolutionär**. Entscheidungen werden nach dem **LRM-Prinzip** (Least Reasonable Moment) so spät wie möglich getroffen, um auf Basis maximaler Informationen zu entscheiden.\n\n**Rolle des Architekten**: Die Architektin ist nicht nur für den technischen Entwurf zuständig, sondern agiert als Kommunikatorin und Vermittlerin zwischen verschiedenen **Stakeholdern** (Fachbereich, Entwicklung, Management, Betrieb).\n\n### Quellen\n*Folien 1.1, Seite 22-66*' + explanation: '### Lösungserklärung\n\n**Prozesse**: Im **klassischen** Vorgehen wird die Architektur vorab detailliert geplant (**Big Design Up Front**). Im **agilen** Prozess entsteht sie **evolutionär**. Entscheidungen werden nach dem **LRM-Prinzip** (Least Reasonable Moment) so spät wie möglich getroffen, um auf Basis maximaler Informationen zu entscheiden.\n\n**Rolle des Architekten**: Die Architektin ist nicht nur für den technischen Entwurf zuständig, sondern agiert als Kommunikatorin und Vermittlerin zwischen verschiedenen **Stakeholdern** (Fachbereich, Entwicklung, Management, Betrieb).\n\n### Quellen\n*Folien 1.1, Seite 22-66*' }, { - id: 'swa-1-2-anforderungen', - title: '1.2 - SWA - Anforderungen & Kontext', + id: 'swa-1-2-anforderungen-a', + title: '1.2 - SWA - Anforderungen & Kontext (Teil 1)', parts: [ { id: '1-2-a', @@ -125,7 +138,14 @@ export const swaExercises1: Exercise[] = [ points: 5, type: 'text', }, - { + ], + explanation: '### Lösungserklärung\n\n**Anforderungsanalyse**: Eine Anforderung muss präzise sein, damit eine gute Architektur entworfen werden kann. Unklarheiten führen zu Fehlentwicklungen.\n\n**Qualitätsszenarien**: Ein Werkzeug, um nicht-funktionale Anforderungen konkret und messbar zu machen. Das Schema (Quelle, Stimulus, etc.) stellt sicher, dass alle relevanten Aspekte bedacht werden.\n\n**ISO/IEC 9126**: Ein Standard zur Klassifizierung von Softwarequalität, der hilft, Diskussionen über Qualität zu strukturieren.\n\n**Randbedingungen & Risikofaktoren**: **Randbedingungen** sind harte Fakten, die die Architektur von außen beeinflussen (z.B. Gesetze, bestehende IT-Infrastruktur). **Risikofaktoren** sind potenzielle Probleme, die aktiv gemanagt werden müssen (z.B. die Unerfahrenheit des Teams mit einer neuen Technologie).\n\n### Quellen\n*Folien 1.2, Seite 15-58*' + }, + { + id: 'swa-1-2-anforderungen-b', + title: '1.2 - SWA - Anforderungen & Kontext (Teil 2)', + parts: [ + { id: '1-2-e', prompt: 'Erstellen Sie ein Systemkontextdiagramm für ein einfaches Online-Shopsystem in Mermaid-Syntax. Berücksichtigen Sie Kunden, ein externes Zahlungssystem und ein externes Versandsystem.', solution: '```mermaid\ngraph TD\n subgraph Systemkontext Online-Shop\n A[Online-Shop] -- Bestelldaten --> B(Kunde)\n B -- Bestellung/Zahlung --> A\n end\n\n A -- Zahlungsanfrage --> C{Zahlungssystem}\n C -- Zahlungsbestätigung --> A\n\n A -- Versandauftrag --> D(Versandsystem)\n D -- Sendungsstatus --> A\n```', @@ -133,6 +153,6 @@ export const swaExercises1: Exercise[] = [ type: 'mermaid', } ], - explanation: '### Lösungserklärung\n\n**Anforderungsanalyse**: Eine Anforderung muss präzise sein, damit eine gute Architektur entworfen werden kann. Unklarheiten führen zu Fehlentwicklungen.\n\n**Qualitätsszenarien**: Ein Werkzeug, um nicht-funktionale Anforderungen konkret und messbar zu machen. Das Schema (Quelle, Stimulus, etc.) stellt sicher, dass alle relevanten Aspekte bedacht werden.\n\n**ISO/IEC 9126**: Ein Standard zur Klassifizierung von Softwarequalität, der hilft, Diskussionen über Qualität zu strukturieren.\n\n**Randbedingungen & Risikofaktoren**: **Randbedingungen** sind harte Fakten, die die Architektur von außen beeinflussen (z.B. Gesetze, bestehende IT-Infrastruktur). **Risikofaktoren** sind potenzielle Probleme, die aktiv gemanagt werden müssen (z.B. die Unerfahrenheit des Teams mit einer neuen Technologie).\n\n**Systemkontextdiagramm**: Zeigt das System als Blackbox und definiert seine Grenzen, indem es alle externen Akteure und die Datenflüsse zwischen ihnen darstellt. Dies schafft ein grundlegendes Verständnis darüber, was Teil des Systems ist und was nicht.\n\n### Quellen\n*Folien 1.2, Seite 15-58*' + explanation: '### Lösungserklärung\n\n**Systemkontextdiagramm**: Zeigt das System als Blackbox und definiert seine Grenzen, indem es alle externen Akteure und die Datenflüsse zwischen ihnen darstellt. Dies schafft ein grundlegendes Verständnis darüber, was Teil des Systems ist und was nicht.\n\n### Quellen\n*Folien 1.2, Seite 15-58*' } ]; diff --git a/data/swa_exercises.2.ts b/data/swa_exercises.2.ts index ea8a6fb..1656d73 100644 --- a/data/swa_exercises.2.ts +++ b/data/swa_exercises.2.ts @@ -1,4 +1,3 @@ - import { Exercise } from '../types'; export const swaExercises2: Exercise[] = [ @@ -66,8 +65,8 @@ export const swaExercises2: Exercise[] = [ explanation: '### Lösungserklärung\n\n**Zweck des Canvas**\nEin Canvas ist ein Kommunikations- und Analysewerkzeug. Das **Architecture Inception Canvas** im Speziellen hilft Teams, zu Beginn eines Projekts schnell ein gemeinsames Verständnis ("Big Picture") für die wichtigsten architektonischen Treiber zu entwickeln. Es strukturiert die Diskussion und stellt sicher, dass wesentliche Aspekte nicht übersehen werden.\n\n**Ausgewählte Kategorien**\n- **Functional Overview:** Fasst den Kern dessen zusammen, was das System tun soll.\n- **Quality Goals:** Zwingt das Team zur Priorisierung der wichtigsten nicht-funktionalen Anforderungen (Qualitätsziele), die die Architektur maßgeblich beeinflussen.\n- **Technical Constraints:** Listet nicht verhandelbare technische Randbedingungen auf, die den Lösungsraum von vornherein einschränken.\n\n### Quellen\n*Folien 2.3, Seite 2-6*' }, { - id: 'swa-2-5-sichten', - title: '2.5 - SWA - Entwurf der Sichten', + id: 'swa-2-5-sichten-a', + title: '2.5 - SWA - Entwurf der Sichten (Teil 1)', parts: [ { id: '2-5-a', @@ -96,7 +95,14 @@ export const swaExercises2: Exercise[] = [ solution: 'Lose Kopplung bedeutet, dass Komponenten nur wenige Details voneinander kennen und über stabile Schnittstellen interagieren. Enge Kopplung bedeutet, dass Komponenten viele Details voneinander kennen. Lose Kopplung ist zu bevorzugen, da sie die Wartbarkeit, Testbarkeit und Flexibilität des Systems verbessert.', points: 5, type: 'text', - }, + } + ], + explanation: '### Lösungserklärung\n\n**Architektursichten** sind verschiedene Perspektiven auf ein System. Die vier Sichten nach Starke (Kontext, Baustein, Laufzeit, Verteilung) sind ein Standard, um Architektur umfassend zu beschreiben.\n\nDie **Bausteinsicht** ist die statische "Landkarte" des Systems. Sie zeigt **Komponenten**, die idealerweise eine klare **Verantwortlichkeit** haben, ihre Implementierung verstecken (**Information Hiding**) und über definierte **Schnittstellen** kommunizieren. Das Ziel ist **lose Kopplung** (wenig Abhängigkeiten) und **hohe Kohäsion** (alles in einer Komponente gehört eng zusammen). Hierbei unterscheidet man **A-Architektur** (fachlich) von **T-Architektur** (technisch).\n\n### Quellen\n*Folien 2.5, Seite 3-55*' + }, + { + id: 'swa-2-5-sichten-b', + title: '2.5 - SWA - Entwurf der Sichten (Teil 2)', + parts: [ { id: '2-5-e', prompt: 'Skizzieren Sie sinnvolle Abhängigkeiten zwischen den Komponenten eines E-Commerce-Systems (OrderManagement, CustomerManagement, ProductCatalog, Payment, Shipping).', @@ -111,20 +117,27 @@ export const swaExercises2: Exercise[] = [ points: 5, type: 'text', }, - { + { id: '2-5-g', prompt: 'Erstellen Sie ein Sequenzdiagramm (Laufzeitsicht) für einen einfachen Bestellprozess in Mermaid-Syntax. Beteiligt sein sollen ein Client, ein OrderService und ein PaymentService.', solution: '```mermaid\nsequenceDiagram\n participant Client\n participant OrderService\n participant PaymentService\n\n Client->>OrderService: createOrder(orderDetails)\n activate OrderService\n OrderService->>PaymentService: processPayment(paymentDetails)\n activate PaymentService\n PaymentService-->>OrderService: paymentSuccessful\n deactivate PaymentService\n OrderService-->>Client: orderConfirmation\n deactivate OrderService\n```', points: 6, type: 'mermaid', }, - { + { id: '2-5-h', prompt: 'Beurteilen Sie kritisch: Ein Entwicklungsteam argumentiert: "Wir brauchen keine expliziten Sichten - unser Code ist gut strukturiert und selbsterklärend."', solution: 'Diese Aussage ist kritisch zu betrachten. Selbst gut strukturierter Code zeigt nur Implementierungsdetails, aber kein "Big Picture". Sichten bieten eine höhere Abstraktionsebene, die für die Kommunikation mit verschiedenen Stakeholdern (Nicht-Entwickler), die Einarbeitung neuer Teammitglieder und für grundlegende Architekturentscheidungen unerlässlich ist.', points: 6, type: 'text', - }, + } + ], + explanation: '### Lösungserklärung\n\nEin gutes **API-Design** ist entscheidend für lose Kopplung. Es sollte präzise, selbsterklärend und stabil sein.\n\nDie **Laufzeitsicht** (z.B. als **Sequenzdiagramm**) zeigt das dynamische Zusammenspiel der statischen Bausteine zur Erfüllung eines Anwendungsfalls. Sie validiert, ob die Bausteinsicht funktioniert.\n\nAuch bei gutem Code sind **explizite Sichten** unverzichtbar. Sie bieten eine Abstraktionsebene über dem Code, die für Kommunikation und das Verständnis des Gesamtsystems ("Big Picture") notwendig ist.\n\n### Quellen\n*Folien 2.5, Seite 3-55*' + }, + { + id: 'swa-2-5-sichten-c', + title: '2.5 - SWA - Entwurf der Sichten (Teil 3)', + parts: [ { id: '2-5-i', prompt: 'In welcher Reihenfolge geht man bei der Sichtenerstellung am besten vor?', @@ -133,6 +146,6 @@ export const swaExercises2: Exercise[] = [ type: 'text', } ], - explanation: '### Lösungserklärung\n\n**Architektursichten** sind verschiedene Perspektiven auf ein System. Die vier Sichten nach Starke (Kontext, Baustein, Laufzeit, Verteilung) sind ein Standard, um Architektur umfassend zu beschreiben. Die **Erstellung erfolgt iterativ**, oft beginnend mit dem Kontext.\n\nDie **Bausteinsicht** ist die statische "Landkarte" des Systems. Sie zeigt **Komponenten**, die idealerweise eine klare **Verantwortlichkeit** haben, ihre Implementierung verstecken (**Information Hiding**) und über definierte **Schnittstellen** kommunizieren. Das Ziel ist **lose Kopplung** (wenig Abhängigkeiten) und **hohe Kohäsion** (alles in einer Komponente gehört eng zusammen). Hierbei unterscheidet man **A-Architektur** (fachlich) von **T-Architektur** (technisch).\n\nEin gutes **API-Design** ist entscheidend für lose Kopplung. Es sollte präzise, selbsterklärend und stabil sein.\n\nDie **Laufzeitsicht** (z.B. als **Sequenzdiagramm**) zeigt das dynamische Zusammenspiel der statischen Bausteine zur Erfüllung eines Anwendungsfalls. Sie validiert, ob die Bausteinsicht funktioniert.\n\nAuch bei gutem Code sind **explizite Sichten** unverzichtbar. Sie bieten eine Abstraktionsebene über dem Code, die für Kommunikation und das Verständnis des Gesamtsystems ("Big Picture") notwendig ist.\n\n### Quellen\n*Folien 2.5, Seite 3-55*' + explanation: '### Lösungserklärung\n\nDie **Erstellung der Sichten erfolgt iterativ**, oft beginnend mit dem Kontext, dann der Bausteinsicht und der Laufzeitsicht im Wechsel, um den Entwurf zu validieren und zu verfeinern.\n\n### Quellen\n*Folien 2.5, Seite 3-55*' } ]; diff --git a/data/swa_exercises.3.ts b/data/swa_exercises.3.ts index 915aa6b..4f3bfb1 100644 --- a/data/swa_exercises.3.ts +++ b/data/swa_exercises.3.ts @@ -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*' } ]; diff --git a/data/swa_exercises.4.ts b/data/swa_exercises.4.ts index 118654d..274e8aa 100644 --- a/data/swa_exercises.4.ts +++ b/data/swa_exercises.4.ts @@ -3,8 +3,8 @@ import { Exercise } from '../types'; export const swaExercises4: Exercise[] = [ { - id: 'swa-3-5-moderne-architekturen', - title: '3.5 - SWA - Moderne Architekturen', + id: 'swa-3-5-moderne-architekturen-a', + title: '3.5 - SWA - Moderne Architekturen (Teil 1)', parts: [ { id: '3-5-a', @@ -33,7 +33,14 @@ export const swaExercises4: Exercise[] = [ solution: 'Modulith:\n(+) Geringere Betriebskomplexität, einfachere Transaktionen, schrittweises Refactoring.\n(-) Gemeinsame Release-Zyklen, begrenzte technologische Freiheit.\n\nMicroservices:\n(+) Unabhängige Entwicklung & Deployment, bessere Skalierbarkeit, technologische Freiheit.\n(-) Höhere Komplexität (verteiltes System), aufwändigere Infrastruktur, Herausforderungen bei Datenkonsistenz.', points: 7, type: 'text', - }, + } + ], + explanation: '### Lösungserklärung\n\n**Modulith**: Ein Kompromiss zwischen Monolith und Microservices. Er behält den einfachen Betrieb eines Monolithen bei, erzwingt aber eine saubere, modulare Innenstruktur, was die Wartbarkeit verbessert.\n\n**Cloud-Eigenschaften (NIST)**: Die fünf Merkmale (On-demand self-service, Broad network access, Resource pooling, Rapid elasticity, Measured service) definieren, was einen echten Cloud-Service von traditionellem Hosting unterscheidet.\n\n**Conway\'s Law**: Stellt einen Zusammenhang zwischen Organisations- und Systemstruktur her. Für Microservices wird es oft umgekehrt genutzt (**Inverse Conway Maneuver**): Man gestaltet die Organisation (kleine, autonome Teams), damit die gewünschte Architektur (kleine, unabhängige Services) entsteht.\n\n### Quellen\n*Folien 3.5, Seite 4-39*' + }, + { + id: 'swa-3-5-moderne-architekturen-b', + title: '3.5 - SWA - Moderne Architekturen (Teil 2)', + parts: [ { id: '3-5-e', prompt: 'Erläutern Sie zwei der vier vorgestellten Resilienz-Patterns (Timeouts, Bulkheads, Fallbacks, Circuit Breaker).', @@ -54,8 +61,8 @@ export const swaExercises4: Exercise[] = [ solution: 'Komponenten:\n1. BookingService: Verwaltet Buchungen.\n2. PaymentService: Wickelt Zahlungen ab.\n\nEvents:\n1. BookingCreatedEvent: Ausgelöst vom BookingService, um den Zahlungsprozess im PaymentService zu initiieren.\n2. PaymentCompletedEvent: Ausgelöst vom PaymentService, um den BookingService zu informieren, dass die Buchung nun bestätigt werden kann.', points: 7, type: 'text', - }, + } ], - explanation: '### Lösungserklärung\n\n**Modulith**: Ein Kompromiss zwischen Monolith und Microservices. Er behält den einfachen Betrieb eines Monolithen bei, erzwingt aber eine saubere, modulare Innenstruktur, was die Wartbarkeit verbessert.\n\n**Cloud-Eigenschaften (NIST)**: Die fünf Merkmale (On-demand self-service, Broad network access, Resource pooling, Rapid elasticity, Measured service) definieren, was einen echten Cloud-Service von traditionellem Hosting unterscheidet.\n\n**Conway\'s Law**: Stellt einen Zusammenhang zwischen Organisations- und Systemstruktur her. Für Microservices wird es oft umgekehrt genutzt (**Inverse Conway Maneuver**): Man gestaltet die Organisation (kleine, autonome Teams), damit die gewünschte Architektur (kleine, unabhängige Services) entsteht.\n\n**Resilienz-Patterns**: In verteilten Systemen sind Teilausfälle normal. Patterns wie **Timeouts** (verhindern ewiges Warten) und **Circuit Breakers** (schützen vor Überlastung gestörter Dienste) sind essenziell, um die Stabilität des Gesamtsystems zu gewährleisten.\n\n**Migration zum Microservice**: Eine "Big Bang"-Migration ist extrem riskant. Ein evolutionärer Ansatz ist besser. Die größten **Probleme** bei der Migration sind oft das Finden der richtigen Service-Grenzen (Schnitt) und der Umgang mit der gemeinsamen Datenbank.\n\n**EDA**: Eine Event-getriebene Architektur entkoppelt Komponenten stark voneinander. Ein Service sendet ein **Event** (z.B. "Buchung erstellt"), andere Services reagieren darauf. Dies erhöht die Resilienz und Skalierbarkeit.\n\n### Quellen\n*Folien 3.5, Seite 4-39*' + explanation: '### Lösungserklärung\n\n**Resilienz-Patterns**: In verteilten Systemen sind Teilausfälle normal. Patterns wie **Timeouts** (verhindern ewiges Warten) und **Circuit Breakers** (schützen vor Überlastung gestörter Dienste) sind essenziell, um die Stabilität des Gesamtsystems zu gewährleisten.\n\n**Migration zum Microservice**: Eine "Big Bang"-Migration ist extrem riskant. Ein evolutionärer Ansatz ist besser. Die größten **Probleme** bei der Migration sind oft das Finden der richtigen Service-Grenzen (Schnitt) und der Umgang mit der gemeinsamen Datenbank.\n\n**EDA**: Eine Event-getriebene Architektur entkoppelt Komponenten stark voneinander. Ein Service sendet ein **Event** (z.B. "Buchung erstellt"), andere Services reagieren darauf. Dies erhöht die Resilienz und Skalierbarkeit.\n\n### Quellen\n*Folien 3.5, Seite 4-39*' } ]; diff --git a/data/swa_exercises.5.ts b/data/swa_exercises.5.ts index 3c06af4..d06f8ec 100644 --- a/data/swa_exercises.5.ts +++ b/data/swa_exercises.5.ts @@ -73,8 +73,8 @@ export const swaExercises5: Exercise[] = [ explanation: '### Lösungserklärung\n\n**Wissenstransfer**: Dokumentation allein ist passiv. Aktiver **Wissenstransfer** in Sessions und Meetings ist entscheidend, um die "Warum"-Fragen zu klären und sicherzustellen, dass die Architektur vom Team verstanden und gelebt wird. Nur so lässt sich Architekturerosion wirksam bekämpfen.\n\n**Architecture Communication Canvas**: Ein Werkzeug, das hilft, das "Big Picture" einer Architektur auf einer Seite zu visualisieren. Es ist ideal für die Kommunikation mit verschiedenen Stakeholdern und lässt sich gut in **agile Prozesse** integrieren.\n\n**Agiler Wissenstransfer**: In **agilen Teams** ist der formale Dokumentationsaufwand oft geringer. Umso wichtiger sind kontinuierliche Kommunikation und leichtgewichtige Werkzeuge. Wissen muss fließen. Statt großer Dokumente werden oft kleine, fokussierte Artefakte (ADRs) und regelmäßige Austauschformate bevorzugt, um mit der hohen Änderungsgeschwindigkeit Schritt zu halten.\n\n### Quellen\n*Folien 4.3, Seite 2-5*' }, { - id: 'swa-4-5-bewertung', - title: '4.5 - SWA - Architekturbewertung mit LASR', + id: 'swa-4-5-bewertung-a', + title: '4.5 - SWA - Architekturbewertung mit LASR (Teil 1)', parts: [ { id: '4-5-a', @@ -90,7 +90,7 @@ export const swaExercises5: Exercise[] = [ points: 6, type: 'text', }, - { + { id: '4-5-c', prompt: 'Nennen Sie ein Beispiel für eine Architekturmetrik.', solution: 'Ein Beispiel ist die ACD/NCCD Metrik (Average Component Dependency). Sie misst die durchschnittliche Anzahl direkter und indirekter Abhängigkeiten einer Komponente. Ein hoher Wert kann auf eine zu starke Kopplung oder zyklische Abhängigkeiten im System hinweisen.', @@ -103,7 +103,14 @@ export const swaExercises5: Exercise[] = [ solution: 'Pre-Mortem ist eine Bewertungstechnik, bei der man sich vorstellt, das Projekt sei in der Zukunft gescheitert. Das Team analysiert dann rückblickend die möglichen Gründe für dieses Scheitern. Dies hilft, proaktiv Risiken zu identifizieren und Gegenmaßnahmen einzuleiten, bevor die Probleme tatsächlich eintreten.', points: 5, type: 'text', - }, + } + ], + explanation: '### Lösungserklärung\n\n**Architektur-Reviews** sind ein entscheidendes Werkzeug zur Qualitätssicherung. Sie helfen, Risiken frühzeitig zu finden und die Architektur zu validieren.\n\nMan unterscheidet **quantitative** (Tool-basierte Metriken) und **qualitative** (Workshop-basierte Diskussion) Analysen. Beide Ansätze ergänzen sich gut.\n\n**Pre-Mortem** ist eine proaktive Risikoanalysetechnik, bei der man ein Scheitern des Projekts annimmt, um dessen mögliche Ursachen zu ergründen.\n\n### Quellen\n*Folien 4.5, Seite 2-24*' + }, + { + id: 'swa-4-5-bewertung-b', + title: '4.5 - SWA - Architekturbewertung mit LASR (Teil 2)', + parts: [ { id: '4-5-e', prompt: 'Beschreiben Sie die vier Hauptschritte der LASR-Methodik.', @@ -111,28 +118,28 @@ export const swaExercises5: Exercise[] = [ points: 8, type: 'text', }, - { + { id: '4-5-f', prompt: 'Erklären Sie, wie das Spinnennetz-Diagramm in LASR verwendet wird.', solution: 'Das Spinnennetz-Diagramm ist das zentrale Visualisierungselement in LASR. Jede seiner Achsen repräsentiert ein priorisiertes Qualitätsziel. Zuerst wird die Ziellinie (grün) eingetragen, die die angestrebten Werte darstellt. Nach der Risikoanalyse wird die Ergebnislinie eingetragen, die die geschätzte tatsächliche Erreichung zeigt. Die Lücken zwischen den Linien machen Problembereiche sofort sichtbar.', points: 6, type: 'text', }, - { + { id: '4-5-g', prompt: 'Nennen Sie zwei Vorteile von LASR gegenüber ATAM.', solution: '1. Geringerer Aufwand: LASR ist schlanker und kann mit dem eigenen Team in kürzerer Zeit durchgeführt werden.\n2. Selbstdurchführbarkeit: LASR kann ohne externe, speziell geschulte Moderatoren durchgeführt werden.', points: 4, type: 'text', }, - { + { id: '4-5-h', prompt: 'Diskutieren Sie Vor- und Nachteile der LASR-Methodik gegenüber rein quantitativen Ansätzen.', solution: 'Vorteile von LASR (qualitativ): Erfasst ganzheitlich qualitative Aspekte und Risiken, die Metriken nicht sehen. Fördert das gemeinsame Verständnis im Team.\nNachteile von LASR: Ergebnisse sind subjektiv und hängen von den Teilnehmern ab. Der Aufwand ist höher als bei automatisierten Messungen.\n\nEin idealer Ansatz kombiniert oft beide Methoden.', points: 6, type: 'text', - }, + } ], - explanation: '### Lösungserklärung\n\n**Architektur-Reviews** sind ein entscheidendes Werkzeug zur Qualitätssicherung. Sie helfen, Risiken frühzeitig zu finden und die Architektur zu validieren.\n\nMan unterscheidet **quantitative** (Tool-basierte Metriken) und **qualitative** (Workshop-basierte Diskussion) Analysen. Beide Ansätze ergänzen sich gut.\n\n**Pre-Mortem** ist eine proaktive Risikoanalysetechnik, bei der man ein Scheitern des Projekts annimmt, um dessen mögliche Ursachen zu ergründen.\n\n**LASR (Lean Architecture-System-Review)** ist eine schlanke, qualitative Review-Methode. Die vier Schritte bauen aufeinander auf:\n1. **Mission Statement**: Klärt das "Warum" des Systems.\n2. **Bewertungsmaßstab**: Definiert die wichtigsten Qualitätsziele als messbare Achsen im **Spinnennetz-Diagramm**.\n3. **Basis-Review**: Findet mittels eines strukturierten **Pre-Mortems** Risiken, die diese Ziele gefährden.\n4. **Zielorientierte Analyse**: Vertieft die Diskussion zu den kritischsten Risiken.\n\nIm Vergleich zu umfassenderen Methoden wie **ATAM** ist **LASR** deutlich leichtgewichtiger und schneller durchführbar.\n\n### Quellen\n*Folien 4.5, Seite 2-24*' + explanation: '### Lösungserklärung\n\n**LASR (Lean Architecture-System-Review)** ist eine schlanke, qualitative Review-Methode. Die vier Schritte bauen aufeinander auf:\n1. **Mission Statement**: Klärt das "Warum" des Systems.\n2. **Bewertungsmaßstab**: Definiert die wichtigsten Qualitätsziele als messbare Achsen im **Spinnennetz-Diagramm**.\n3. **Basis-Review**: Findet mittels eines strukturierten **Pre-Mortems** Risiken, die diese Ziele gefährden.\n4. **Zielorientierte Analyse**: Vertieft die Diskussion zu den kritischsten Risiken.\n\nIm Vergleich zu umfassenderen Methoden wie **ATAM** ist **LASR** deutlich leichtgewichtiger und schneller durchführbar.\n\n### Quellen\n*Folien 4.5, Seite 2-24*' } ]; diff --git a/data/swa_exercises.6.ts b/data/swa_exercises.6.ts index d402afc..25f2b1c 100644 --- a/data/swa_exercises.6.ts +++ b/data/swa_exercises.6.ts @@ -3,8 +3,8 @@ import { Exercise } from '../types'; export const swaExercises6: Exercise[] = [ { - id: 'swa-6-1-ddd-strategic', - title: '6.1 - SWA - Domain-Driven Design (Strategic)', + id: 'swa-6-1-ddd-strategic-a', + title: '6.1 - SWA - Domain-Driven Design (Strategic Teil 1)', parts: [ { id: '6-1-a', @@ -33,7 +33,14 @@ export const swaExercises6: Exercise[] = [ solution: '1. Student Management Context: Verwaltung von Studentendaten, Einschreibungen, Studienverläufe.\n2. Course Management Context: Kursplanung, Vorlesungsverzeichnis, Raumbelegung.\n3. Examination Context: Prüfungsorganisation, Notenverwaltung, Prüfungstermine.', points: 6, type: 'text', - }, + } + ], + explanation: '### Lösungserklärung\n\n**Strategic Design** ist der Teil von DDD, der sich mit der "großen" Architektur befasst: der Zerlegung eines komplexen Systems in handhabbare Teile.\n\n- **Ubiquitous Language**: Das Fundament. Eine gemeinsame Sprache zwischen Entwicklern und Fachexperten, um Missverständnisse zu vermeiden.\n- **Bounded Context**: Eine explizite Grenze, innerhalb derer ein Modell und eine Sprache gültig sind. Ein Begriff wie "Produkt" kann im Verkaufs-Kontext etwas anderes bedeuten als im Lager-Kontext. Bounded Contexts sind die Blaupause für Microservices.\n\n### Quellen\n*Folien 6.1, Seite 3-19*' + }, + { + id: 'swa-6-1-ddd-strategic-b', + title: '6.1 - SWA - Domain-Driven Design (Strategic Teil 2)', + parts: [ { id: '6-1-e', prompt: 'Was ist eine Context Map und wofür wird sie verwendet?', @@ -48,7 +55,7 @@ export const swaExercises6: Exercise[] = [ points: 6, type: 'text', }, - { + { id: '6-1-g', prompt: 'Klassifizieren Sie die Bereiche eines E-Commerce-Systems (Order Management, Payment, Inventory Management) in Core, Supporting oder Generic und begründen Sie Ihre Entscheidung.', solution: '- Order Management (Core Domain): Dies ist der Kerngeschäftsprozess, der direkt Umsatz generiert und einen Wettbewerbsvorteil darstellt.\n- Inventory Management (Supporting Subdomain): Es unterstützt das Kerngeschäft, ist aber selbst kein Differenzierungsmerkmal.\n- Payment (Generic Subdomain): Dies ist eine allgemeine Funktionalität, die oft von externen Dienstleistern (z.B. Stripe, PayPal) als Standardlösung eingekauft wird.', @@ -61,7 +68,14 @@ export const swaExercises6: Exercise[] = [ solution: 'Conway\'s Law besagt, dass die Architektur eines Systems die Kommunikationsstruktur der Organisation widerspiegelt. Für Bounded Contexts ist dies relevant, da die Grenzen eines Contexts idealerweise den Grenzen eines Entwicklungsteams entsprechen sollten. Dies fördert die Autonomie und reduziert den Kommunikationsaufwand zwischen den Teams.', points: 5, type: 'text', - }, + } + ], + explanation: '### Lösungserklärung\n\n- **Context Map**: Eine Visualisierung der Beziehungen zwischen Bounded Contexts. Sie zeigt, wie die Teams und Systeme zusammenarbeiten müssen (z.B. über ein **Shared Kernel**, **Customer-Supplier** oder einen **Anti-Corruption Layer**).\n- **Core/Supporting/Generic Subdomains**: Diese Klassifizierung hilft, den Fokus zu lenken. Die meiste Energie sollte in die **Core Domain** fließen, da sie den einzigartigen Geschäftswert schafft. **Generic Subdomains** (z.B. Authentifizierung) sollten als Standardlösung eingekauft werden.\n- **Conway\'s Law**: Dieses Gesetz untermauert das Design. Die Systemarchitektur (Bounded Contexts) und die Organisationsstruktur (Teams) sollten aufeinander abgestimmt sein, um die Kommunikation zu optimieren und Autonomie zu ermöglichen.\n\n### Quellen\n*Folien 6.1, Seite 3-19*' + }, + { + id: 'swa-6-1-ddd-strategic-c', + title: '6.1 - SWA - Domain-Driven Design (Strategic Teil 3)', + parts: [ { id: '6-1-i', prompt: 'Inwiefern sind Team Topologies eine Alternative zu Strategic Design?', @@ -77,6 +91,6 @@ export const swaExercises6: Exercise[] = [ type: 'text', } ], - explanation: '### Lösungserklärung\n\n**Strategic Design** ist der Teil von DDD, der sich mit der "großen" Architektur befasst: der Zerlegung eines komplexen Systems in handhabbare Teile.\n\n- **Ubiquitous Language**: Das Fundament. Eine gemeinsame Sprache zwischen Entwicklern und Fachexperten, um Missverständnisse zu vermeiden.\n- **Bounded Context**: Eine explizite Grenze, innerhalb derer ein Modell und eine Sprache gültig sind. Ein Begriff wie "Produkt" kann im Verkaufs-Kontext etwas anderes bedeuten als im Lager-Kontext. Bounded Contexts sind die Blaupause für Microservices.\n- **Context Map**: Eine Visualisierung der Beziehungen zwischen Bounded Contexts. Sie zeigt, wie die Teams und Systeme zusammenarbeiten müssen (z.B. über ein **Shared Kernel**, **Customer-Supplier** oder einen **Anti-Corruption Layer**).\n- **Core/Supporting/Generic Subdomains**: Diese Klassifizierung hilft, den Fokus zu lenken. Die meiste Energie sollte in die **Core Domain** fließen, da sie den einzigartigen Geschäftswert schafft. **Generic Subdomains** (z.B. Authentifizierung) sollten als Standardlösung eingekauft werden.\n- **Conway\'s Law & Team Topologies**: Diese Gesetze und Modelle untermauern das Design. Die Systemarchitektur (Bounded Contexts) und die Organisationsstruktur (Teams) sollten aufeinander abgestimmt sein, um die Kommunikation zu optimieren und Autonomie zu ermöglichen. **Team Topologies** bietet hierzu ein praktisches Vokabular (z.B. **Stream-Aligned Teams**, **Platform Teams**).\n\n### Quellen\n*Folien 6.1, Seite 3-19*' + explanation: '### Lösungserklärung\n\n- **Team Topologies**: Bietet ein praktisches Vokabular (z.B. **Stream-Aligned Teams**, **Platform Teams**) um die Organisationsstruktur an der Systemarchitektur auszurichten und so die kognitive Last der Teams zu reduzieren.\n\n### Quellen\n*Folien 6.1, Seite 3-19*' } ]; diff --git a/data/swa_exercises.7.ts b/data/swa_exercises.7.ts index 283fc00..78139d5 100644 --- a/data/swa_exercises.7.ts +++ b/data/swa_exercises.7.ts @@ -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*' } ];