#81 Integrate additions to chapter 2

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
@@ -20,14 +21,15 @@
 ==== 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.
+* Autonomie und Zusammenarbeit: Sicherstellung der Entwicklungsautonomie durch Reduzierung der Abstimmungsaufwände zwischen Teams
+* Fachliche Kohäsion: Ausrichtung der Modul-Schnitte auf fachliche Themengebiete und wertschöpfende, erwünschte Team-Beziehungen (da sich diese Beziehungen in Schnittstellen und Abhängigkeiten in den Systemen dieser Teams wiederfinden werden).
 
 [[LZ-2-4]]
 ==== LZ 2-4: 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
@@ -40,8 +42,8 @@
 ==== LZ 2-6: 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 +53,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 designation 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
@@ -62,13 +65,14 @@
 [[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.
+* Autonomy and collaboration: Ensuring development autonomy by reducing the coordination effort between teams.
+* Domain cohesion: Aligning module boundaries with business domains and fostering value-adding, desirable team relationships (as these relationships will manifest in the interfaces and dependencies within the teams' systems).
 
 [[LG-2-4]]
 ==== LG 2-4: 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
@@ -79,8 +83,8 @@
 [[LG-2-6]]
 ==== LG 2-6: 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[]