Integrated review comments and translation

docs/04-integration/02-learning-goals.adoc

@@ -4,38 +4,41 @@
 [[LZ-4-1]]
 ==== LZ 4-1: Integrationsstrategien gegenüberstellen (am Beispiel von DDD Strategic Design)
 
-* Strategic Design aus dem Domain-Driven Design (DDD) und dessen Beziehungspatterns (z. B. Anti-Corruption Layer, Shared Kernel, Customer/Supplier) verstehen und erklären
-* Modulgrenzen eines Systems anhand von "Bounded Context" darstellen, beschreiben und SOLL/IST-Vergleiche anstellen
-* Anhand der Qualitätsziele begründen welche Patterns aus dem Strategic Design für eine Integration/Schnittstelle verwendet werden können und welche Patterns nicht 
+* Strategic Design aus dem Domain-Driven Design (DDD) und dessen Beziehungspatterns (z. B. Anti-Corruption Layer, Shared Kernel, Customer/Supplier) verstehen und erklären.
+* Modulgrenzen eines Systems anhand von "Bounded Context" darstellen, beschreiben und SOLL/IST-Vergleiche anstellen.
+* Anhand der Qualitätsziele begründen welche Patterns aus dem Strategic Design für eine Integration/Schnittstelle verwendet werden können und welche Patterns nicht.
+
 [[LZ-4-2]]
- ==== LZ 4-2: Technische Integrationsmechanismen auswählen und begründen
+==== LZ 4-2: Technische Integrationsmechanismen auswählen und begründen
 
- * Bewertung der Vor- und Nachteile von technischen Integrationsmechanismen wie Frontend-Integration, Middle-Tier Integration (REST, RPC, Messaging) oder Datenbankintegration anhand spezifischer Qualitätsziele des System und notwendiger Erfahrung/Skills der betreuenden Entwicklungsteams.
-* (OPTIONAL) Frontend-Integration (Links, Client-Side Includes, Microfrontends, etc.) und Middleware für Legacy-Systeme sowie deren Auswirkungen vergleichen
+* Bewertung der Vor- und Nachteile von technischen Integrationsmechanismen wie Frontend-Integration, Middle-Tier Integration (REST, RPC, Messaging) oder Datenbankintegration anhand spezifischer Qualitätsziele des System und notwendiger Erfahrung/Skills der betreuenden Entwicklungsteams.
+* (OPTIONAL) Frontend-Integration (Links, Client-Side Includes, Microfrontends, etc.) und Middleware für Legacy-Systeme sowie deren Auswirkungen vergleichen.
 * (OPTIONAL) Praktische Anwendung in brow-field Szenarien: Integration von Legacy-Datenmodellen durch Transformation und Mapping.
 
-[[LZ-4-2]]
-==== LZ 4-2: Konsistenzmodelle erklären und auswählen (CAP Theorem)
+[[LZ-4-3]]
+==== LZ 4-3: Konsistenzmodelle erklären und auswählen (CAP Theorem)
 
 * Erklärung des CAP-Theorems: Abwägung zwischen Konsistenz, Verfügbarkeit und Partitionstoleranz.
-* Notwendigkeit von Partitionstoleranz verstehen
-* Vergleich von ACID- und BASE-Modellen: Garantien, Verluste und Tradeoffs sowie daraus resultierende Einsatzmöglichkeiten in verteilten Systemen verstehen
-* Unterschied zwischen "Consistency" bei ACID und BASE anhand praktischer Beispiele erklären 
-* (OPTIONAL) Praxisbeispiel zu ACID-Transaktionen und BASE-Transaktionen in verteilten Systemen
-* CP- vs. AP-Systemdesign anhand von Qualitätszielen begründen
-* Praxisbeispiel: Wahl eines geeigneten Konsistenzmodells basierend auf Systemanforderungen wie Latenz und Skalierbarkeit.
-
-[[LZ-4-3]]
+* Notwendigkeit von Partitionstoleranz verstehen.
+* Vergleich von ACID- und BASE-Modellen: Garantien, Verluste und Tradeoffs sowie daraus resultierende Einsatzmöglichkeiten in verteilten Systemen verstehen.
+* Unterschied zwischen "Consistency" bei ACID und BASE anhand praktischer Beispiele erklären.
+* (OPTIONAL) Praxisbeispiel zu ACID-Transaktionen und BASE-Transaktionen in verteilten Systemen.
+* CP- vs. AP-Systemdesign anhand von Qualitätszielen begründen.
+* (OPTIONAL) Praxisbeispiel: Wahl eines geeigneten Konsistenzmodells basierend auf Systemanforderungen wie Latenz und Skalierbarkeit.
+* (OPTIONAL) Produktbeispiele aus unterschiedlichen Kategorien (z. B. NoSQL, Konfigurationswerkzeuge, Service Discovery) kennen.
+
+[[LZ-4-4]]
 ==== LZ 4-4: Resilience Patterns benennen
 
-* Messaging Patterns: Request/Reply, Publish/Subscribe und deren Resilience-Eigenschaften.
+* (OPTIONAL) Messaging Patterns: Request/Reply, Publish/Subscribe und deren Resilience-Eigenschaften.
 * Resilience-Strategien für dezentrale Datenhaltung und redundante Architektur.
-* Nutzung von Mechanismen wie Circuit Breaker, Graceful Degradation und Bulkhead zur Sicherstellung der Verfügbarkeit.
+* Unterschiede zwischen High-Availability und Resilience verstehen und Praxisbeispiele nennen
+* (OPTIONAL) Nutzung von Mechanismen wie Circuit Breaker, Bulkhead und Graceful Degradation zur Sicherstellung der Verfügbarkeit in Szenarien, wo Systemteile unterschiedliche Verfügbarkeitsanforderungen haben.
 
 [[LZ-4-5]]
 ==== LZ 4-5: Sicherheitsauswirkungen von Integrationsmethoden kennen und berücksichtigen
 
-* Vergleich von Authentifizierungs- und Autorisierungsmechanismen (z. B. OAuth, Kerberos).
+* (OPTIONAL) Vergleich von Authentifizierungs- und Autorisierungsmechanismen (z. B. OAuth, Kerberos).
 * Auswirkungen von synchroner (z. B. RPC) vs. asynchroner Integration (z. B. Messaging) auf Sicherheit und Datenintegrität.
 * Implementierung sicherer Schnittstellen und Makroarchitektur für verteilte Systeme.
 
@@ -51,38 +54,52 @@
 // tag::EN[]
 
 [[LG-4-1]]
-==== LG 4-1: Compare Integration Strategies (using DDD Strategic Design as an example)
+==== LG 4-1: Compare Integration Strategies (Using the Example of DDD Strategic Design)
 
-* Understand Strategic Design from Domain-Driven Design (DDD) for integration (e.g., Anti-Corruption Layer, Shared Kernel, Bounded Context).
-* Evaluate the pros and cons of integration approaches like REST, Messaging, or Database Integration based on specific quality goals.
-* Utilize Frontend Integration and Middleware for legacy systems.
-Practical application: Integrate old data models through transformation and mapping.
+* Understand and explain Strategic Design from Domain-Driven Design (DDD) and its relationship patterns (e.g., Anti-Corruption Layer, Shared Kernel, Customer/Supplier).  
+* Represent and describe the module boundaries of a system using "Bounded Context" and perform AS-IS/TO-BE comparisons.  
+* Justify which patterns from Strategic Design can or cannot be used for an integration/interface based on quality goals.  
 
 [[LG-4-2]]
-==== LG 4-2: Explain and Select Consistency Models (CAP Theorem)
+==== LG 4-2: Select and Justify Technical Integration Mechanisms
 
-* Explain the CAP Theorem: Trade-offs between Consistency, Availability, and Partition Tolerance.
-* Compare ACID and BASE models: Use cases in distributed systems.
-* Practical example: Choosing an appropriate consistency model based on system requirements like latency and scalability.
+* Evaluate the advantages and disadvantages of technical integration mechanisms such as frontend integration, middle-tier integration (REST, RPC, Messaging), or database integration based on specific quality goals of the system and the required experience/skills of the development teams.  
+* (Optional) Compare frontend integration (e.g., links, client-side includes, microfrontends) and middleware for legacy systems and their impacts.  
+* (Optional) Practical application in brownfield scenarios: integration of legacy data models through transformation and mapping.  
 
 [[LG-4-3]]
-==== LG 4-3: Identify Resilience Patterns
-* Messaging Patterns: Request/Reply, Publish/Subscribe, and their resilience properties.
-* Resilience Strategies for decentralized data storage and redundant architectures.
-* Use mechanisms like Circuit Breaker, Graceful Degradation, and Bulkhead to ensure availability.
+==== LG 4-3: Explain and Select Consistency Models (CAP Theorem)
+
+* Explain the CAP theorem: trade-offs between consistency, availability, and partition tolerance.  
+* Understand the necessity of partition tolerance.  
+* Compare ACID and BASE models: guarantees, compromises, and trade-offs, as well as their resulting applicability in distributed systems.  
+* Explain the difference between "consistency" in ACID and BASE using practical examples.  
+* (Optional) Provide practical examples of ACID and BASE transactions in distributed systems.  
+* Justify CP vs. AP system design based on quality goals.  
+* (Optional) Practical example: choosing a suitable consistency model based on system requirements such as latency and scalability.  
+* (Optional) Know product examples from different categories (e.g., NoSQL, configuration tools, service discovery).  
 
 [[LG-4-4]]
-==== LG 4-4: Understand and Consider Security Impacts of Integration Methods
+==== LG 4-4: Identify and select Resilience Patterns
 
-* Compare Authentication and Authorization mechanisms (e.g., OAuth, Kerberos).
-* Explore the security and data integrity implications of synchronous (e.g., RPC) vs. asynchronous integration (e.g., Messaging).
-* Implement secure interfaces and macro-architectures for distributed systems.
+* (Optional) Messaging Patterns: Request/Reply, Publish/Subscribe, and their resilience properties.  
+* Resilience strategies for decentralized data storage and redundant architecture.  
+* Understand the differences between high availability and resilience and provide practical examples.  
+* (Optional) Use mechanisms like Circuit Breaker, Bulkhead, and Graceful Degradation to ensure availability in scenarios where system components have different availability requirements.  
+* Understand the impact of resilience patterns on well-known operations metrics like MTTR and MTBF and their interdependency with fast delivery of bugfixes/releases.
 
 [[LG-4-5]]
-==== LG 4-5: (OPTIONAL) Understand and Design Event-Driven Architectures
+==== LG 4-5: Understand and Consider Security Implications of Integration Methods
+
+* (Optional) Compare authentication and authorization mechanisms (e.g., OAuth, Kerberos).  
+* Analyze the impact of synchronous (e.g., RPC) vs. asynchronous integration (e.g., Messaging) on security and data integrity.  
+* Implement secure interfaces and macroarchitecture for distributed systems.  
+
+[[LG-4-6]]
+==== LG 4-6: (Optional) Understand and Design Event-Driven Architectures (EDA)
 
-* Introduction to Event-Driven Architectures (EDA): Publishing Domain Events to decouple systems.
-* Design an EDA using messaging systems like RabbitMQ or Kafka.
-* Address challenges and solutions for Backpressure and decentralized data storage.
+* Introduction to Event-Driven Architectures (EDA): publishing domain events to decouple systems.  
+* Design an EDA with messaging systems like RabbitMQ or Kafka.  
+* Address challenges and solutions for backpressure and decentralized data storage.  
 
 // end::EN[]