97 lines
7.7 KiB
TypeScript
97 lines
7.7 KiB
TypeScript
|
|
import { Exercise } from '../types';
|
|
|
|
export const swaExercises6: Exercise[] = [
|
|
{
|
|
id: 'swa-6-1-ddd-strategic-a',
|
|
title: '6.1 - SWA - Domain-Driven Design (Strategic Teil 1)',
|
|
parts: [
|
|
{
|
|
id: '6-1-a',
|
|
prompt: 'Was ist Domain-Driven Design (DDD) und was sind seine Kernprinzipien?',
|
|
solution: 'DDD ist ein Ansatz zur Entwicklung komplexer Software, bei dem die Geschäftsdomäne im Mittelpunkt steht. Kernprinzipien sind: \n1. Fokus auf die Geschäftsdomäne und ihre Logik.\n2. Entwicklung einer gemeinsamen "Ubiquitous Language" zwischen Fachexperten und Entwicklern.\n3. Ein modellgetriebenes Design, bei dem das Domänenmodell direkt in Code umgesetzt wird.',
|
|
points: 5,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '6-1-b',
|
|
prompt: 'Erläutern Sie die Ubiquitous Language. Warum ist sie wichtig?',
|
|
solution: 'Die Ubiquitous Language ist eine gemeinsame, eindeutige Sprache, die von allen Projektbeteiligten (Entwickler, Fachexperten, etc.) verwendet wird. Sie ist wichtig, weil sie Missverständnisse reduziert und sicherstellt, dass das Domänenmodell im Code exakt die Geschäftsdomäne widerspiegelt.',
|
|
points: 4,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '6-1-c',
|
|
prompt: 'Definieren Sie Bounded Context und erklären Sie dessen Bedeutung für DDD.',
|
|
solution: 'Ein Bounded Context definiert die Grenzen, innerhalb derer ein bestimmtes Domänenmodell und die Ubiquitous Language gültig sind. Die Bedeutung liegt in der Komplexitätsbewältigung: Große, komplexe Domänen werden in handhabbare, autonome Teile zerlegt. Dies ermöglicht unabhängige Teamarbeit und technische Entscheidungen pro Kontext.',
|
|
points: 5,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '6-1-d',
|
|
prompt: 'Erstellen Sie drei mögliche Bounded Contexts für ein Universitätsverwaltungssystem.',
|
|
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?',
|
|
solution: 'Eine Context Map visualisiert die Beziehungen und Integrationsmuster zwischen verschiedenen Bounded Contexts. Sie wird verwendet, um Abhängigkeiten zu verstehen und die Teamkoordination zu organisieren. Sie definiert, wie die Kontexte technisch und organisatorisch zusammenarbeiten.',
|
|
points: 5,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '6-1-f',
|
|
prompt: 'Erklären Sie die Relationship Patterns: Shared Kernel, Customer-Supplier und Anti-Corruption Layer.',
|
|
solution: '- Shared Kernel: Zwei oder mehr Kontexte teilen sich einen gemeinsamen Codebereich, den sie gemeinsam entwickeln. Führt zu enger Kopplung.\n- Customer-Supplier: Ein Kontext (Supplier) liefert Services für einen anderen (Customer), wobei der Customer die Entwicklung des Suppliers beeinflusst.\n- Anti-Corruption Layer: Eine Übersetzungsschicht schützt den eigenen Kontext vor den Modellen und der Komplexität eines anderen (oft externen oder veralteten) Kontexts.',
|
|
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.',
|
|
points: 6,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '6-1-h',
|
|
prompt: 'Erklären Sie „Conway\'s Law" und dessen Relevanz für das Design von Bounded Contexts.',
|
|
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?',
|
|
solution: 'Team Topologies bieten eine alternative, oft praktischere Herangehensweise. Während Strategic Design sich stark auf die fachliche Domäne konzentriert, um Grenzen zu finden, berücksichtigen Team Topologies auch andere "Fracture Planes" (Aufteilungskriterien) wie Technologie, Compliance oder geografische Verteilung. Sie sind explizit organisationsgetrieben.',
|
|
points: 6,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '6-1-j',
|
|
prompt: 'Nennen Sie zwei der vier Team-Typen von Team Topologies und beschreiben Sie kurz deren Funktion.',
|
|
solution: '1. Stream-Aligned Teams: Arbeiten an einem kontinuierlichen Wertstrom, der auf ein Geschäftsergebnis ausgerichtet ist. Sie sind End-to-End für einen Service verantwortlich.\n2. Platform Teams: Stellen interne Services und Tools als Self-Service-Plattform bereit, um die Produktivität der Stream-Aligned Teams zu erhöhen und deren kognitive Last zu reduzieren.',
|
|
points: 5,
|
|
type: 'text',
|
|
}
|
|
],
|
|
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*'
|
|
}
|
|
];
|