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

17
data/swa_exercises.4.ts
View File

@ -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*'
}
];