From 40c1bf34c59a1d43ce6f7cf987a05d7f71c393f3 Mon Sep 17 00:00:00 2001 From: Falk Sippach Date: Sun, 1 Dec 2024 00:27:27 +0100 Subject: [PATCH 1/4] #81 Integrate additions to chapter 2 --- docs/02-modularization/02-learning-goals.adoc | 24 +++++++++++-------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/docs/02-modularization/02-learning-goals.adoc b/docs/02-modularization/02-learning-goals.adoc index 01c3573..f6ab464 100644 --- a/docs/02-modularization/02-learning-goals.adoc +++ b/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[] From 809b484b74e8858001dddac0b13eb27d6f92fbdd Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sun, 1 Dec 2024 01:29:13 +0100 Subject: [PATCH 2/4] Update docs/02-modularization/02-learning-goals.adoc --- docs/02-modularization/02-learning-goals.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/02-modularization/02-learning-goals.adoc b/docs/02-modularization/02-learning-goals.adoc index f6ab464..4b7f3e2 100644 --- a/docs/02-modularization/02-learning-goals.adoc +++ b/docs/02-modularization/02-learning-goals.adoc @@ -54,7 +54,7 @@ * 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 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. +* 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 From 618bb47e27036c1f7b39737a06bcbf7fd90e36e0 Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sun, 1 Dec 2024 01:29:19 +0100 Subject: [PATCH 3/4] Update docs/02-modularization/02-learning-goals.adoc --- docs/02-modularization/02-learning-goals.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/02-modularization/02-learning-goals.adoc b/docs/02-modularization/02-learning-goals.adoc index 4b7f3e2..cbe417f 100644 --- a/docs/02-modularization/02-learning-goals.adoc +++ b/docs/02-modularization/02-learning-goals.adoc @@ -65,7 +65,7 @@ [[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 reducing the coordination effort between teams. +* Autonomy and collaboration: Ensuring development autonomy by reducing the coordination effort between teams (e.g. by explicitly choosing matching DDD patterns and simplifying interfaces). * 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]] From 7093016247ea0cf8cf929eafbef011fc3b05559f Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sun, 1 Dec 2024 01:29:26 +0100 Subject: [PATCH 4/4] Update docs/02-modularization/02-learning-goals.adoc --- docs/02-modularization/02-learning-goals.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/02-modularization/02-learning-goals.adoc b/docs/02-modularization/02-learning-goals.adoc index cbe417f..899d5a6 100644 --- a/docs/02-modularization/02-learning-goals.adoc +++ b/docs/02-modularization/02-learning-goals.adoc @@ -21,7 +21,7 @@ ==== 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 Reduzierung der Abstimmungsaufwände zwischen Teams +* Autonomie und Zusammenarbeit: Sicherstellung der Entwicklungsautonomie durch Reduzierung der Abstimmungsaufwände zwischen Teams (bspw. durch explizite Wahl von DDD Patterns und Vereinfachung der Schnittstellen) * 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]]