Merge branch 'main' into 80-update-overall-curriculum-structure-and-c…

…hapter-durations

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

@@ -23,17 +23,7 @@
 - Die Vorteile verschiedener Isolationsarten (Devtime, Runtime, Deployment, Team) bewerten
 
 [[LZ-1-3]]
-==== LZ 1-3: Wechselwirkung von Architekturtypen und Organisation analysieren und benennen
-
-- Erklären, wie Beziehungen zwischen Teams und Organisationseinheiten die Architektur von Systemen und damit Aspekte wie Abstimmungsaufwände und Time-to-Market beeinflussen
-- Erkennen, wie Conway's Law die Entwicklungsgeschwindigkeit beeinflusst
-- Den Zusammenhang zwischen Teamgrenzen und Systemgrenzen analysieren und erklären
-- 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
-
-[[LZ-1-4]]
-==== LZ 1-4: Kompromisse der vorgestellten Architekturtypen vermitteln und adaptieren
+==== LZ 1-3: Kompromisse der vorgestellten Architekturtypen vermitteln und adaptieren
 
 - Die Vor- und Nachteile verschiedener Architekturstile abwägen
 - Wissen, wie man Architekturentscheidungen dem Business-Kontext anpasst
@@ -43,8 +33,8 @@
 - Die Kosten von Verteilung und Service-Kommunikation realistisch einschätzen
 
 
-[[LZ-1-5]]
-==== LZ 1-5: Langfristige Qualitätsziele von flexiblen Architekturen benennen
+[[LZ-1-4]]
+==== LZ 1-4: Langfristige Qualitätsziele von flexiblen Architekturen benennen
 
 - Zentrale Qualitätsmerkmale flexibler Architekturen kennen
 - Verstehen, warum Flexibilität und schnelles Feedback strategische Ziele sind
@@ -54,8 +44,8 @@
 - Die Rolle von Reproduzierbarkeit und Vorhersagbarkeit verstehen
 - Automatisierbarkeit als Qualitätsziel erkennen
 
-[[LZ-1-6]]
-==== LZ 1-6: Typische Architekturentscheidungen von flexiblen Architekturen erklären und begründen
+[[LZ-1-5]]
+==== LZ 1-5: Typische Architekturentscheidungen von flexiblen Architekturen erklären und begründen
 
 - Architekturentscheidungen durch Businessziele und Qualitätsszenarien begründen
 - Die Notwendigkeit bestimmter Architekturmuster erklären
@@ -97,17 +87,7 @@
 - Evaluate benefits of different isolation types (devtime, runtime, deployment, team)
 
 [[LG-1-3]]
-==== LG 1-3: Analyze and Define the Interplay Between Architecture Types and Organization
-
-- Explain how relationships between teams and organizational units influence system architecture, affecting coordination overhead and time-to-market
-- Recognize how Conway's Law impacts development speed
-- Analyze and explain the correlation between team boundaries and system boundaries
-- Explain the balance between technical and organizational structure
-- Explain differences between buildtime and runtime dependencies in software development processes
-- Understand parallel software development capability as an architectural goal
-
-[[LG-1-4]]
-==== LG 1-4: Communicate and Adapt Trade-offs of Presented Architecture Types
+==== LG 1-3: Communicate and Adapt Trade-offs of Presented Architecture Types
 
 - Weigh advantages and disadvantages of different architectural styles
 - Know how to adapt architectural decisions to business context
@@ -116,8 +96,8 @@
 - Understand when combining different architectural styles makes sense
 - Realistically assess costs of distribution and service communication
 
-[[LG-1-5]]
-==== LG 1-5: Define Long-term Quality Goals of Flexible Architectures
+[[LG-1-4]]
+==== LG 1-4: Define Long-term Quality Goals of Flexible Architectures
 
 - Know core quality characteristics of flexible architectures
 - Understand why flexibility and rapid feedback are strategic goals
@@ -127,8 +107,8 @@
 - Understand the role of reproducibility and predictability
 - Recognize automation capability as a quality goal
 
-[[LG-1-6]]
-==== LG 1-6: Explain and justify Typical Architectural Decisions in Flexible Architectures
+[[LG-1-5]]
+==== LG 1-5: Explain and justify Typical Architectural Decisions in Flexible Architectures
 
 - Justify architectural decisions through business goals and quality scenarios
 - Explain the necessity of specific architectural patterns

docs/01-motivation/references.adoc

@@ -1,6 +1,6 @@
 === {references}
 
-<<humblecd>>, <<wolffcd>>, <<humbleacd>>
+<<wolffcd>>, <<humbleacd>>, <<fowler>>, <<takada>>
 
 
 

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

@@ -7,7 +7,8 @@
 
 * 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 Kontext-Mapping.
+* 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
 
 [[LZ-2-2]]
 ==== LZ 2-2: Unterschiedliche Arten von Bausteinen beschreiben und begründen
@@ -17,31 +18,25 @@
 * Isolationsebenen: Unterschiede zwischen modularer Isolation im Code, in der Laufzeitumgebung und bei Netzwerkschnittstellen.
 
 [[LZ-2-3]]
-==== LZ 2-3: Kommunikationsstruktur der Organisation bei Zerlegung berücksichtigen
-
-* Conway’s Law: Bedeutung und Auswirkungen der Kommunikationsstruktur der Organisation auf die Wahl und Gestaltung von Modulgrenzen.
-* Autonomie und Zusammenarbeit: Sicherstellung der Entwicklungsautonomie durch modulare Schnitte entlang fachlicher Grenzen.
-
-[[LZ-2-4]]
-==== LZ 2-4: Modularisierungskonzepte bewerten und auswählen
+==== LZ 2-3: Modularisierungskonzepte bewerten und auswählen
 
 * 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: Auswahl einer Modularisierung passend zu Anforderungen wie Parallelisierung der Entwicklung oder unabhängiges Deployment.
+* Qualitätsziele berücksichtigen: Auswahl von Modularisierungskonzepten anhand von Anforderungen wie "Parallelisierbarkeit der Entwicklung" oder "unabhängiges Deployment von Modulen".
 
-[[LZ-2-5]]
-==== LZ 2-5: Modularisierungsstrategien bewerten
+[[LZ-2-4]]
+==== LZ 2-4: Modularisierungsstrategien bewerten
 
 * Strategien und Konsequenzen: Bewertung der Auswirkungen verschiedener Modularisierungsansätze, z. B. Monolith vs. verteilte Module.
 * Technologieabhängigkeit: Wie Modularisierungstechnologien (z. B. Container oder Laufzeitumgebungen) Strategien beeinflussen.
 * Aufwands-Nutzen-Abgleich: Abwägung organisatorischer und technischer Aufwände gegen die erwarteten Vorteile.
 
-[[LZ-2-6]]
-==== LZ 2-6: Aufwand und Nutzen von Modularisierungsstrategien gegenüberstellen
+[[LZ-2-5]]
+==== LZ 2-5: Aufwand und Nutzen von Modularisierungsstrategien gegenüberstellen
 
 * Integration vs. Dezentralisierung: Identifikation von organisatorischen und technischen Aufwänden  für die Integration modularer Systeme.
-* Erwartete Vorteile: Bewertung des Nutzens, wie etwa unabhängiges Deployment, Parallelisierung und verbesserte Verständlichkeit.
-* Modulgrenzen und Komplexität: Analyse, wie die Wahl der Modulgrenzen die Komplexität und den Entwicklungsaufwand beeinflusst.
+* Erwartete Vorteile: Bewertung des Nutzens, wie etwa unabhängiges Deployment, Parallelisierung der Arbeit, Austauschbarkeit von Technologien und verbesserte Verständlichkeit durch klar benannte Module und Integrationspunkte.
+* Modulgrenzen und Komplexität: Analyse, wie die Wahl der Modulgrenzen die Komplexität, den Abstimmungsaufwand bei Änderungen sowie die Entwicklungs- und Wartungskosten beeinflusst.
 
 // end::DE[]
 
@@ -51,7 +46,8 @@
 ==== LG 2-1: Designing decomposition into components based on requirements
 * Decomposition approaches: Creating a system decomposition into components while considering functional and technical requirements.
 * Strategic Design: Using Domain-Driven Design (DDD) to define module boundaries based on business domains (e.g., Bounded Contexts).
-* Hierarchical structures: Considering the hierarchy of modules in the decomposition, such as subdomains and context mapping.
+* Hierarchical structures: Considering the hierarchy of modules during decomposition, such as subdomains and context mapping.
+* Naming with clear semantics: Components require a name and a description that leave no ambiguity about their purpose and function.
 
 [[LG-2-2]]
 ==== LG 2-2: Describing and justifying different types of components
@@ -60,27 +56,22 @@
 * Levels of isolation: Differentiating modular isolation in code, runtime environments, and network interfaces.
 
 [[LG-2-3]]
-==== LG 2-3: Considering the communication structure of the organization during decomposition
-* Conway’s Law: Understanding the importance and impact of the organization’s communication structure on the choice and design of module boundaries.
-* Autonomy and collaboration: Ensuring development autonomy by aligning modular cuts with business boundaries.
-
-[[LG-2-4]]
-==== LG 2-4: Evaluating and selecting modularization concepts
+==== LG 2-3: Evaluating and selecting modularization concepts
 * Technical modularization: Assessing concepts such as files, libraries, processes, microservices, or self-contained systems.
 * Integration and coupling: Analyzing levels of coupling (source code, compile-time, network protocols) and their implications.
-* Quality goals: Choosing modularization approaches suitable for requirements like development parallelization or independent deployment.
+* Considering quality goals: Selecting modularization concepts based on requirements such as "development parallelization" or "independent module deployment."
 
-[[LG-2-5]]
-==== LG 2-5: Assessing modularization strategies
+[[LG-2-4]]
+==== LG 2-4: Assessing modularization strategies
 * Strategies and consequences: Evaluating the impact of different modularization approaches, e.g., monolith vs. distributed modules.
 * Technology dependency: How modularization technologies (e.g., containers or runtime environments) influence strategies.
 * Effort-benefit trade-offs: Weighing organizational and technical efforts against expected benefits.
 
-[[LG-2-6]]
-==== LG 2-6: Contrasting the costs and benefits of modularization strategies
+[[LG-2-5]]
+==== LG 2-5: Contrasting the costs and benefits of modularization strategies
 * Integration vs. decentralization: Identifying organizational and technical costs for integrating modular systems.
-* Expected benefits: Assessing advantages such as independent deployment, parallelization, and improved system comprehensibility.
-* Module boundaries and complexity: Analyzing how module boundary choices affect complexity and development effort.
+* Expected benefits: Assessing advantages such as independent deployment, parallelization of work, replaceability of technologies, and improved system comprehensibility due to clearly named modules and integration points.
+* Module boundaries and complexity: Analyzing how module boundary choices affect complexity, coordination effort for changes, and development and maintenance costs.
 
 // end::EN[]
 

docs/02-modularization/references.adoc

@@ -1,5 +1,5 @@
 === {references}
 
-<<evansddd>>, <<fowler>>, <<twelvefactor>>, <<wolffms>>, <<newman>>, <<parnas>>
+<<evansddd>>, <<fowler>>, <<wolffms>>, <<newman>>, <<parnas>>