Merge pull request #83 from isaqb-org/81-integrate-additions-to-chapt…

…er-2

#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
@@ -21,7 +22,7 @@
 
 * 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-4]]
 ==== LZ 2-4: Modularisierungsstrategien bewerten
@@ -34,8 +35,8 @@
 ==== 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[]
 
@@ -45,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
@@ -57,7 +59,7 @@
 ==== 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-4]]
 ==== LG 2-4: Assessing modularization strategies
@@ -68,8 +70,8 @@
 [[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[]