Skip to content

02-learning-goals.adoc

Latest commit

 

History

History
106 lines (62 loc) · 5.53 KB

02-learning-goals.adoc

File metadata and controls

106 lines (62 loc) · 5.53 KB

{learning-goals}

LZ 2-1: Dekomposition in Bausteine anhand der Anforderungen entwerfen

LZ 2-2: Unterschiedliche Arten von Bausteinen beschreiben und begründen

  • Arten von Modulen: Definition und Eigenschaften verschiedener Bausteine, wie Microservices, Self-contained Systems und Deployment-Monolithen.

  • Lebenszyklus von Modulen: Beschreibung, wie ein Baustein erstellt, integriert, getestet, deployt und skaliert wird.

  • Isolationsebenen: Unterschiede zwischen modularer Isolation im Code, in der Laufzeitumgebung und bei Netzwerkschnittstellen.

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ätsanforderungen berücksichtigen: Auswahl von Modularisierungskonzepten anhand von Anforderungen wie "Parallelisierbarkeit der Entwicklung" oder "unabhängiges Deployment von Modulen".

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-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 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.

LG 2-1: Goals of modularization

  • Architects understand that flexibility in the context of this curriculum means the ability to adapt the system to changing requirements.

  • Architects understand the role of information hiding to achieve flexibility, specifically the hiding of decisions that are difficult to make or may change later.

  • Architects can use modularization to map conceptual building blocks to (technical) modules.

  • Architects know the impact on modularization of requirements such as independent deployment, parallelization of work, and replaceability of technologies.

LG 2-2: Coupling

  • Architects understand that the goal of modularization is to reduce coupling between modules.

  • Architects understand possible causes of tight coupling between modules, such as misplaced module boundaries, ill-designed APIs, and over-constrained communication between modules.

  • Architects understand the special role of mutable state in tight coupling.

  • Architects can design a modularization in a bottom-up fashion that will keep coupling low.

  • Architects can decrease coupling by increasing cohesion within modules.

LG 2-3: Modularization and the organization

  • Architects can analyze how module boundary choices affect complexity, coordination effort for changes, and development and maintenance costs.

  • Architects understand the role of Conway’s law in constraining modularization.

  • Architects understand the possibility of changing the organization to match the modularization (Inverse-Conway-Maneuver).

  • Architects understand the need to decompose a system into coarse-grained building blocks before modules exist, and can draft a such a decomposition for a system top-down according to known requirements.

  • Architects can apply Context Mapping to design such a decomposition.

  • Architects know alternatives to Context Mapping for coarse-grain system decomposition.

  • Architects can identify organizational and technical costs for integrating a modular system.

  • Architects understand the different communication challenges in organizations that organize teams by bounded contexts and those that organize them by technical competency.

LG 2-4: Module mechanisms

  • Architects understand programming-language mechanisms that relate to modularization such as classes and interfaces in object-oriented languages, namespace mechanisms, and ML-style module languages.

  • Architects understand the role of opaque interfaces in enforcing loose coupling.

  • Architects know interface languages and their differences such as Java/C# interfaces, Java modules, and ML-style module signatures, and can leverage them to enforce loose coupling.

  • Architects know non-linguistic (not built into the programming language) approaches to enforcing modularization such as creating unit tests and using external tools that operate on the module dependency graph.

  • Architects understand the relationship between module mechanisms and deployment strategies.

LG 2-5: Modularization documentation

  • Architects understand that architecture documentation and implementation modularization should be aligned.

  • Architects can document the principles and rules of the modularization strategy.

  • Architects know that architecture documentation can be generated from appropriate modularization mechanisms.