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

26
data/swa_exercises.6.ts
View File

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