Draft: Redo "modularization" and "distribution".

docs/02-modularization/00-structure.adoc

@@ -3,11 +3,11 @@
 // ====================================================
 
 // tag::DE[]
-== Modularisierung von Systemen in Teilsysteme
+== Modularisierung
 // end::DE[]
 
 // tag::EN[]
-== Modularization of Systems of Systems
+== Modularization
 // end::EN[]
 
 include::01-duration-terms.adoc[{include_configuration}]

docs/02-modularization/01-duration-terms.adoc

@@ -21,12 +21,12 @@
 
 === Terms and Principles
 
-- Motivation for decompositioning into smaller systems
-- Different kinds of modularisation, coupling
-- System limits as a way of isolation
-- Hierarchical structure
-- Application, Self-contained System, Microservice
-- Domain-Driven Design Concepts and "Strategic Design", Bounded Contexts
-
+- Flexibility as the ability to change the system
+- Relationship between modularization, coupling, and cohesion
+- Bottom-up and top-down modularization
+- Module mechanisms
+- Context mapping
+- Modularization and deployment
+- Inverse-Conway-Maneuver
 
 // end::EN[]

docs/02-modularization/02-learning-goals.adoc

@@ -5,10 +5,6 @@
 [[LZ-2-1]]
 ==== LZ 2-1: Dekomposition in Bausteine anhand der Anforderungen entwerfen
 
-* 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 Context-Mapping.
-* Namen 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
@@ -43,44 +39,68 @@
 // tag::EN[]
 
 [[LG-2-1]]
-==== 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 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-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]]
-==== LG 2-2: Describing and justifying different types of components
-* Types of modules: Defining and identifying characteristics of different components, such as microservices, self-contained systems, and deployment monoliths.
-* Lifecycle of components: Explaining how a component is created, integrated, tested, deployed, and scaled.
-* Levels of isolation: Differentiating modular isolation in code, runtime environments, and network interfaces.
+==== 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]]
-==== 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.
-* Considering quality requirements: Selecting modularization concepts based on requirements such as "development parallelization" or "independent module deployment."
+==== LG 2-3: Modularization and the organization
 
-[[LG-2-4]]
-==== LG 2-4: Assessing modularization strategies
-* Strategies and consequences: Evaluating the impact of different modularization approaches, e.g., monolith vs. distributed modules.
-* Technology dependency: How modularization technologies (e.g., containers or runtime environments) influence strategies.
-* Effort-benefit trade-offs: Weighing organizational and technical efforts against expected benefits.
+* Architects can analyze how module boundary choices affect complexity, coordination effort for changes, and development and maintenance costs.
 
-[[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 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.
+* Architects understand the role of Conway's law in constraining modularization.
 
-// end::EN[]
+* 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]]
+==== 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]]
+==== 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.
+
+// end::EN[]

docs/02-modularization/references.adoc

@@ -1,5 +1,5 @@
 === {references}
 
-<<evansddd>>, <<fowler>>, <<wolffms>>, <<newman>>, <<parnas>>
+<<evansddd>>, <<fowler>>, <<wolffms>>, <<newman>>, <<parnas>>, <<minskymadhavapeddy>>, <<parlog>>
 
 

docs/03-modules-organization/00-structure.adoc → docs/03-distribution/00-structure.adoc

@@ -7,7 +7,7 @@
 // end::DE[]
 
 // tag::EN[]
-== Software Modules and the Organization
+== Distribution
 // end::EN[]
 
 include::01-duration-terms.adoc[{include_configuration}]

docs/03-modules-organization/01-duration-terms.adoc → docs/03-distribution/01-duration-terms.adoc

@@ -14,5 +14,25 @@ Conway's Law, Kommunikationsstrukturen, Context Mapping, Strategic Design, Stake
 |===
 
 === Terms and Principles
-Conway's Law, Communication structures, Context Mapping, strategic design, stakeholder management, Team Topologies, socio-technical Architectures, teamautonomy, Team and system boundaries, Macro- vs. Micro architecture decisons.
+
+* microservice
+
+* self-contained system
+
+* leverage
+
+* velocity
+
+* queue
+
+* flow control/backpressure
+
+* ACID
+
+* CAP theorem
+
+* BASE
+
+* event sourcing
+
 // end::EN[]

docs/03-modules-organization/02-learning-goals.adoc → docs/03-distribution/02-learning-goals.adoc

@@ -42,41 +42,85 @@
 // end::DE[]
 
 // tag::EN[]
+
 [[LG-3-1]]
-==== LG 3-1: Analyze and name the interaction between architecture types and organization
+==== LG 3-1: Distribution tradeoffs and challenges
+
+Software architects understand the implementation tradeoffs between monolithic and distributed systems:
+
+* independent deployment of modules
+
+* compile-time interopability checks
+
+* velocity shipping new features to production
+
+* leverage from re-using code among subsystems
+
+* difficulty of moving module boundaries
+
+Software architects understand the communication and implementation challenges in distributed systems:
 
-* Explain how relationships between teams or organizational units influence the architecture of systems, impacting coordination efforts and time-to-market
-* Recognize how Conway's Law affects the development speed and adaptability of systems
-* Analyze and explain the relationship between team boundaries and system boundaries
-* [OPTIONAL] Explain the balance between technical and organizational structure
-* Explain the differences between build-time and runtime dependencies for software development processes
-* Understand the parallelizability of software development tasks as an architectural goal
-* [OPTIONAL] Describe how organizational changes affect software and vice versa, enabling informed decisions for organizational and software architecture
+* communication delivery failure
+
+* overload from divergent processing rates in the overall system
+
+* network latency
+
+* security
+
+* observability
+
+* testing
+
+* fault localization
 
 [[LG-3-2]]
-==== LG 3-2: Consider the organization's communication structure when decomposing
+==== LG 3-2: Distribution strategy
+
+* Software architects can choose appropriate module boundaries to separate services.
+
+* Software architects understand the tradeoffs of request/response communication vs. fire-and-forget.
 
-* Conway's Law: Understand the significance and impact of the organization's communication structure on the choice and design of module boundaries.
-* Autonomy and Collaboration: Ensure development autonomy through modular cuts along business boundaries.
+* Software architects understand that distributed systems involve both implicit and explicit queues.
+
+* Software architects can design a communication strategy between services in a distributed system.
+
+* Software architects can design an architecture for achieving horizontal scalability using microservices.
+
+* Software architects can implement an appropriate communication strategy for a self-contained systems architecture.
 
 [[LG-3-3]]
-==== LG 3-3: Use context maps for stakeholder management
+==== LG 3-3: Distribution mechanisms
+
+* Software architects know mechanisms for communication in a distributed system such as REST, SOAP, GraphQL, gRPC, Thrift, event feeds, and message-oriented middleware.
 
-* Use context maps from Domain-Driven Design (DDD) to represent the  current state (AS-IS) and a desired future state (TO-BE) of a system landscape.
-* [OPTIONAL] Understand and apply context maps as a communication and planning tool depending on the target audience (developers vs. management).
+* Software architects know languages for interfaces in distributed systems such as Protocol, WSDL, JSON schemas, XML schemas, GraphQL schemas, OpenAPI, and AsyncAPI.
 
-[[LG-3-4]]
-==== LG 3-4: [OPTIONAL] Use terms like team organization and socio-technical architectures confidently
+* Software architects can choose appropriate technologies and conventions for implementing communication in a distributed system.
 
-* Classify terms such as team organization, socio-technical architectures, and similar concepts.
-* Explain their meaning in the context of modern software development.
-* Develop an understanding of the link between technical and social aspects in architecture design.
+* Software architects can implement flow control/backpressure in a distributed system to ameliorate overload.
+
+* Software architects can design appropriate fault detection and mitigation strategies.
 
 [[LG-3-5]]
-==== LG 3-5: Identify macro-architecture decisions made outside your sphere of influence
+==== LG 3-5: Distributed state
+
+* Software architects can design an appropriate strategy for maintaining distributed state.
+
+* Software architects understand the difficulty of achieving ACID in a distributed setting.
+
+* Software architects understand the tradeoffs implied in the CAP theorem.
+
+* Software architects can decide when BASE is an appropriate strategy for maintaining distributed state.
+
+* Software architects can utilize events for maintaining distributed state.
+
+[[LG-3-5]]
+==== LG 3-5: Distribution and the organization
+
+* Software architects understand the tradeoffs between using common modules across organizational units and "shared nothing" strategies.
+
+* Software architects can choose and implement high-leverage abstractions (such as platform, libraries, DSLs) across organizational units.
+
 
-* Understand the difference between micro and macro architecture to identify and proactively address potential constraints and coordination efforts.
-* Understand the distinction between macro and micro architecture to identify potential limitations and opportunities in deployment strategies.
-* Analyze macro-architecture decisions such as communication protocols, operational standards, and platform requirements, and evaluate their impact on deployment and runtime methods.
-* Recognize the importance of central platform standards for the efficiency of communication and deployments/software deliveries.
 // end::EN[]

docs/03-distribution/references.adoc

@@ -0,0 +1,5 @@
+=== {references}
+
+<<wolffms>>, <<tanenbaum>>, <<takada>>, <<newman>>, <<fowler>>, <<hanmer>>, <<hamilton>>, <<brewer>>
+
+

docs/99-references/00-references.adoc

@@ -36,6 +36,10 @@ This section contains references that are cited in the curriculum.
 - [[[fowler,Lewis, Fowler, et al. 2013]]] James Lewis, Martin Fowler, et al.: Microservices - http://martinfowler.com/articles/microservices.html, 2013
 - [[[lamport,Lamport 1998]]] Leslie Lamport, The Part-Time Parliament, ACM Transactions on Computer Systems 16, 2 (May 1998), 133-169
 
+**M**
+
+- [[[minskymadhavapeddy, Minsky, Madhavapeddy 2022]]] Yaron Minsky, Anil Madhavapeddy: Real-World OCaml. Cambridge University Press, 2022.
+
 **N**
 
 - [[[newman,Sam Newman 2021]]] Sam Newman: Building Microservices: Designing Fine-Grained Systems, O'Reilly Media, 2nd ed. edition, 2021, ISBN 978-1-49203-402-5
@@ -47,6 +51,8 @@ This section contains references that are cited in the curriculum.
 
 **P**
 
+- [[[parlog, Parlog 2019]]] Nicolai Parlog, The Java Module System, Manning, 2019.
+
 - [[[parnas,Parnas 1972]]] David Parnas, On the Criteria To Be Used
   in Decomposing Systems into Modules.  Communications of the ACM
   15(12):1053--1058, 1972.

docs/config/setup.adoc

@@ -17,16 +17,16 @@
 :duration-chapter1-practice: 30
 :duration-chapter2-content: 120
 :duration-chapter2-practice: 60
-:duration-chapter3-content: 90
+:duration-chapter3-content: 150
 :duration-chapter3-practice: 60
 :duration-chapter4-content: 150
 :duration-chapter4-practice: 60
 :duration-chapter5-content: 90
 :duration-chapter5-practice: 90
 :duration-chapter6-content: 90
 :duration-chapter6-practice: 60
-:duration-total-content: 600 (10h)
-:duration-total-practice: 360 (6h)
+:duration-total-content: FIXME
+:duration-total-practice: FIXME
 
 ifeval::["{language}" == "DE"]
 :curriculum-name: Flexible Architekturmodelle - Modularisierung, Integration und Betrieb von modernen Softwaresystemen

docs/curriculum-flex.adoc

@@ -39,7 +39,7 @@ include::01-motivation/00-structure.adoc[{include_configuration}]
 
 include::02-modularization/00-structure.adoc[{include_configuration}]
 
-include::03-modules-organization/00-structure.adoc[{include_configuration}]
+include::03-distribution/00-structure.adoc[{include_configuration}]
 
 include::04-integration/00-structure.adoc[{include_configuration}]