Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#81 Integrate additions to chapter 2 #83

Merged
merged 5 commits into from
Dec 1, 2024
Merged

#81 Integrate additions to chapter 2 #83

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
40c1bf3
#81 Integrate additions to chapter 2
sippsack Nov 30, 2024
809b484
Update docs/02-modularization/02-learning-goals.adoc
aheusingfeld Dec 1, 2024
618bb47
Update docs/02-modularization/02-learning-goals.adoc
aheusingfeld Dec 1, 2024
7093016
Update docs/02-modularization/02-learning-goals.adoc
aheusingfeld Dec 1, 2024
c10659c
Merge branch 'main' into 81-integrate-additions-to-chapter-2
aheusingfeld Dec 1, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 14 additions & 10 deletions docs/02-modularization/02-learning-goals.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
aheusingfeld marked this conversation as resolved.
Show resolved Hide resolved
* 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
Expand All @@ -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[]

Expand All @@ -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.
aheusingfeld marked this conversation as resolved.
Show resolved Hide resolved

[[LG-2-2]]
==== LG 2-2: Describing and justifying different types of components
Expand All @@ -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.
aheusingfeld marked this conversation as resolved.
Show resolved Hide resolved
* 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
Expand All @@ -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[]

Expand Down