Merge pull request #86 from isaqb-org/fixes-ben

Improvements

docs/00b-basics/03-timing-didactics-and-more.adoc

@@ -1,7 +1,7 @@
 :recommended-duration-in-days: 3
 :methodical-credits: 10
 :technical-credits: 20
-:communicative-credits: 00
+:communicative-credits: 0
 
 // tag::DE[]
 === Dauer, Didaktik und weitere Details

docs/00b-basics/05-curriculum-outline.adoc

@@ -7,9 +7,7 @@ Die einzelnen Abschnitte des Lehrplans sind gemäß folgender Gliederung beschri
 - **Unterrichts-/Übungszeit**: Legt die Unterrichts- und Übungszeit fest, die für dieses Thema bzw. dessen Übung in einer akkreditierten Schulung mindestens aufgewendet werden muss.
 - **Lernziele**: Beschreibt die zu vermittelnden Inhalte inklusive ihrer Kernbegriffe und -konzepte.
 
-Dieser Abschnitt skizziert damit auch die zu erwerbenden Kenntnisse in entsprechenden Schulungen.
-
-.Der Aufbau der Kapitel folgt einer klaren Progression:
+Dieser Abschnitt skizziert damit auch die zu erwerbenden Kenntnisse in entsprechenden Schulungen. Der Aufbau der Kapitel folgt einer klaren Progression:
 
 - Erst das große Bild verstehen
 - Dann die Voraussetzungen kennen
@@ -29,9 +27,7 @@ The individual sections of the curriculum are described according to the followi
 - **Teaching/practice time**: Defines the minimum amount of teaching and practice time that must be spent on this topic or its practice in an accredited training course.
 - **Learning goals**: Describes the content to be conveyed including its core terms and principles.
 
-This section therefore also outlines the skills to be acquired in corresponding training courses.
-
-.The structure of the chapters follows a clear progression:
+This section therefore also outlines the skills to be acquired in corresponding training courses. The structure of the chapters follows a clear progression:
 
 - First, understand the big picture
 - Then, know the prerequisites

docs/01-motivation/02-learning-goals.adoc

@@ -5,7 +5,7 @@
 [[LZ-1-1]]
 ==== LZ 1-1: Themen und Buzzwords einordnen
 
-- Erklären, wie sich Architekturstile wie Microservices, Self-Contained Systems, Modulithen und Monolithen unterscheiden
+- Erklären, wie sich Architekturstile wie Microservices, Self-contained Systems, Modulithen und Monolithen unterscheiden
 - Die Rolle von DevOps und Continuous Delivery im Kontext flexibler Architekturen verstehen
 - Den Zusammenhang zwischen Cloud Computing und flexiblen Architekturen erkennen
 - Aktuelle Architektur-Trends anhand gegebener Qualitätsziele einschätzen und bewerten

docs/02-modularization/01-duration-terms.adoc

@@ -9,7 +9,7 @@
 - Unterschiedliche Arten von Modularisierung, Kopplung
 - Systemgrenzen als Mittel für Isolation
 - Hierarchische Struktur
-- Anwendung, Applikation, Self-Contained System, Microservice
+- Anwendung, Applikation, Self-contained System, Microservice
 - Domain-Driven Design-Konzepte und „Strategic Design“, Bounded Contexts
 
 // end::DE[]
@@ -25,7 +25,7 @@
 - Different kinds of modularisation, coupling
 - System limits as a way of isolation
 - Hierarchical structure
-- Application, Self-Contained System, Microservice
+- Application, Self-contained System, Microservice
 - Domain-Driven Design Concepts and "Strategic Design", Bounded Contexts
 
 

docs/02-modularization/02-learning-goals.adoc

@@ -8,19 +8,19 @@
 * Zerlegungsansätze: Erstellung einer Systemzerlegung in Bausteine unter Berücksichtigung fachlicher und technischer Anforderungen.
 * Strategic Design: Einsatz von Domain-Driven Design (DDD) zur Definition von Modulgrenzen anhand fachlicher Domänen (z. B. Bounded Contexts).
 * Hierarchische Strukturen: Berücksichtigung der Hierarchie von Modulen bei der Zerlegung, z. B. Subdomänen und Context-Mapping.
-* Benamung mit eindeutiger Semantik: Bausteine benötigen eine Bezeichnung und eine Beschreibung, die keinen Zweifel an ihrem Sinn und Funktion lassen
+* Namen mit eindeutiger Semantik: Bausteine benötigen eine Bezeichnung und eine Beschreibung, die keinen Zweifel an ihrem Sinn und Funktion lassen
 
 [[LZ-2-2]]
 ==== LZ 2-2: Unterschiedliche Arten von Bausteinen beschreiben und begründen
 
-* Arten von Modulen: Definition und Eigenschaften verschiedener Bausteine, wie Microservices, Self-Contained Systems und Deployment-Monolithen.
+* Arten von Modulen: Definition und Eigenschaften verschiedener Bausteine, wie Microservices, Self-contained Systems und Deployment-Monolithen.
 * Lebenszyklus von Modulen: Beschreibung, wie ein Baustein erstellt, integriert, getestet, deployt und skaliert wird.
 * Isolationsebenen: Unterschiede zwischen modularer Isolation im Code, in der Laufzeitumgebung und bei Netzwerkschnittstellen.
 
 [[LZ-2-3]]
 ==== LZ 2-3: Modularisierungskonzepte bewerten und auswählen
 
-* Technische Modularisierung: Bewertung von Konzepten wie Dateien, Bibliotheken, Prozesse, Microservices oder Self-Contained Systems.
+* Technische Modularisierung: Bewertung von Konzepten wie Dateien, Bibliotheken, Prozesse, Microservices oder Self-contained Systems.
 * Integration und Kopplung: Analyse von Kopplungsebenen (Sourcecode, Kompilate, Netzwerkprotokoll) und deren Auswirkungen.
 * Qualitätsziele berücksichtigen: Auswahl von Modularisierungskonzepten anhand von Anforderungen wie "Parallelisierbarkeit der Entwicklung" oder "unabhängiges Deployment von Modulen".
 
@@ -79,7 +79,7 @@
 
 
 
-· 
+·
 
 
 

docs/03-modules-organization/02-learning-goals.adoc

@@ -7,10 +7,10 @@
 - Erklären, wie Beziehungen zwischen Teams bzw. Organisationseinheiten die Architektur von Systemen beeinflussen und damit Auswirkungen auf Abstimmungsaufwände und Time-to-Market haben
 - Erkennen, wie Conway's Law die Entwicklungsgeschwindigkeit und Änderungsfähigkeit von Systemen beeinflusst
 - Den Zusammenhang zwischen Teamgrenzen und Systemgrenzen analysieren und erklären
-- (OPTIONAL) Die Balance zwischen technischer und organisatorischer Struktur erklären
+- [OPTIONAL] Die Balance zwischen technischer und organisatorischer Struktur erklären
 - Unterschiede von Buildtime- und Runtime-Abhängigkeiten für Softwareentwicklungsprozesse erklären
 - Die Parallelisierbarkeit von Softwareentwicklungsaufgaben als Architekturziel verstehen
-- (OPTIONAL) Darstellen wie organisatorische Änderungen die Software beeinflussen und umgekehrt, um bewusste Entscheidungen für Organisations- und Softwarearchitektur treffen zu können.
+- [OPTIONAL] Darstellen wie organisatorische Änderungen die Software beeinflussen und umgekehrt, um bewusste Entscheidungen für Organisations- und Softwarearchitektur treffen zu können.
 
 [[LZ-3-2]]
 ==== LZ 3-2: Kommunikationsstruktur der Organisation bei Zerlegung berücksichtigen
@@ -21,11 +21,11 @@
 [[LZ-3-3]]
 ==== LZ 3-3: Context Maps für Stakeholder Management nutzen
 
-* Context Maps aus Domain-Driven Design (DDD) einsetzen, um den aktuellen IST-Zustand und einen gewünschten zukünftigen SOLL-Zustand einer Systemlandschaft darzustellen. 
-* (OPTIONAL) Context Maps zielgruppenabhängig (Entwickler vs. Management) als Kommunikations- und Planungswerkzeug verstehen und anwenden.
+* Context Maps aus Domain-Driven Design (DDD) einsetzen, um den aktuellen IST-Zustand und einen gewünschten zukünftigen SOLL-Zustand einer Systemlandschaft darzustellen.
+* [OPTIONAL] Context Maps zielgruppenabhängig (Entwickler vs. Management) als Kommunikations- und Planungswerkzeug verstehen und anwenden.
 
 [[LZ-3-4]]
-==== LZ 3-4: (OPTIONAL) Begriffe wie Teamorganisation und sozio-technische Architekturen sicher verwenden
+==== LZ 3-4: [OPTIONAL] Begriffe wie Teamorganisation und sozio-technische Architekturen sicher verwenden
 
 * Begriffe wie Team-Organisation, sozio-technische Architekturen und ähnliche Konzepte einordnen.
 * Bedeutung im Kontext moderner Softwareentwicklung erklären.
@@ -48,10 +48,10 @@
 * Explain how relationships between teams or organizational units influence the architecture of systems, impacting coordination efforts and time-to-market
 * Recognize how Conway's Law affects the development speed and adaptability of systems
 * Analyze and explain the relationship between team boundaries and system boundaries
-* (OPTIONAL) Explain the balance between technical and organizational structure
+* [OPTIONAL] Explain the balance between technical and organizational structure
 * Explain the differences between build-time and runtime dependencies for software development processes
 * Understand the parallelizability of software development tasks as an architectural goal
-* (OPTIONAL) Describe how organizational changes affect software and vice versa, enabling informed decisions for organizational and software architecture
+* [OPTIONAL] Describe how organizational changes affect software and vice versa, enabling informed decisions for organizational and software architecture
 
 [[LG-3-2]]
 ==== LG 3-2: Consider the organization's communication structure when decomposing
@@ -63,10 +63,10 @@
 ==== LG 3-3: Use context maps for stakeholder management
 
 * Use context maps from Domain-Driven Design (DDD) to represent the  current state (AS-IS) and a desired future state (TO-BE) of a system landscape.
-* (OPTIONAL) Understand and apply context maps as a communication and planning tool depending on the target audience (developers vs. management).
+* [OPTIONAL] Understand and apply context maps as a communication and planning tool depending on the target audience (developers vs. management).
 
 [[LG-3-4]]
-==== LG 3-4: (OPTIONAL) Use terms like team organization and socio-technical architectures confidently
+==== LG 3-4: [OPTIONAL] Use terms like team organization and socio-technical architectures confidently
 
 * Classify terms such as team organization, socio-technical architectures, and similar concepts.
 * Explain their meaning in the context of modern software development.

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

@@ -10,10 +10,10 @@
 
 [[LZ-4-2]]
 ==== 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.
-* (OPTIONAL) Praktische Anwendung in brow-field Szenarien: Integration von Legacy-Datenmodellen durch Transformation und Mapping.
+
+* 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, Micro-Frontends, 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-3]]
 ==== LZ 4-3: Konsistenzmodelle erklären und auswählen (CAP Theorem)
@@ -22,28 +22,28 @@
 * 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.
+* [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.
+* [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
 
-* (OPTIONAL) 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.
 * 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.
+* [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
 
-* (OPTIONAL) 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.
 
 [[LZ-4-6]]
-==== LZ 4-6: (OPTIONAL) Event-getriebene Architekturen kennen und entwerfen
+==== LZ 4-6: [OPTIONAL] Event-getriebene Architekturen kennen und entwerfen
 
 * Einführung in Event-Driven Architectures (EDA): Publizieren von Domain Events zur Entkopplung von Systemen.
 * Entwurf einer EDA mit Messaging-Systemen wie RabbitMQ oder Kafka.
@@ -56,50 +56,50 @@
 [[LG-4-1]]
 ==== LG 4-1: Compare Integration Strategies (Using the Example of DDD Strategic Design)
 
-* 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.  
+* 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: Select and Justify Technical Integration Mechanisms
 
-* 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.  
+* 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, micro frontends) 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: 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).  
+* 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: Identify and select Resilience Patterns
 
-* (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.  
+* (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: 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.  
+* (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 with 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[]