diff --git a/docs/02-modularization/00-structure.adoc b/docs/02-modularization/00-structure.adoc index e0f45d7..ebedea5 100644 --- a/docs/02-modularization/00-structure.adoc +++ b/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}] diff --git a/docs/02-modularization/01-duration-terms.adoc b/docs/02-modularization/01-duration-terms.adoc index 599d87e..7e613ec 100644 --- a/docs/02-modularization/01-duration-terms.adoc +++ b/docs/02-modularization/01-duration-terms.adoc @@ -21,12 +21,11 @@ === 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 +- Modularization and deployment +- Inverse-Conway-Maneuver // end::EN[] diff --git a/docs/02-modularization/02-learning-goals.adoc b/docs/02-modularization/02-learning-goals.adoc index fcca3f2..a4c85d4 100644 --- a/docs/02-modularization/02-learning-goals.adoc +++ b/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,72 @@ // 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 that software interfaces imply communication between humans. +* Architects understand that, for an external interface to remains useful to many different clients, you need to have a process that governs changes. +* 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 design a coarse-grain system decomposition. -· +* Architects can produce an appropriate visualization of the system decomposition. +* Architects know different techniques for coarse-grain system decomposition and their tradeoffs. +* Architects can identify organizational and technical costs for integrating a modular system. +[[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 packages, .NET namespaces, and ML-style module signatures, and can leverage them to enforce loose coupling. + +* Architects know non-linguistic (not built into the programming language) architecture-management approaches to enforcing modularization such as creating 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 must 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[] diff --git a/docs/02-modularization/references.adoc b/docs/02-modularization/references.adoc index c49d6b7..aead8bd 100644 --- a/docs/02-modularization/references.adoc +++ b/docs/02-modularization/references.adoc @@ -1,5 +1,6 @@ + === {references} -<>, <>, <>, <>, <> +<>, <>, <>, <>, <>, <>, <>, <> diff --git a/docs/03-modules-organization/00-structure.adoc b/docs/03-distribution/00-structure.adoc similarity index 91% rename from docs/03-modules-organization/00-structure.adoc rename to docs/03-distribution/00-structure.adoc index b729220..371523e 100644 --- a/docs/03-modules-organization/00-structure.adoc +++ b/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}] diff --git a/docs/03-modules-organization/01-duration-terms.adoc b/docs/03-distribution/01-duration-terms.adoc similarity index 70% rename from docs/03-modules-organization/01-duration-terms.adoc rename to docs/03-distribution/01-duration-terms.adoc index 76563e7..a29cb57 100644 --- a/docs/03-modules-organization/01-duration-terms.adoc +++ b/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 + +* velocity + +* queue + +* flow control/backpressure + +* ACID + +* CAP theorem + +* BASE + +* event sourcing + +* macro architecture + // end::EN[] diff --git a/docs/03-modules-organization/02-learning-goals.adoc b/docs/03-distribution/02-learning-goals.adoc similarity index 51% rename from docs/03-modules-organization/02-learning-goals.adoc rename to docs/03-distribution/02-learning-goals.adoc index 3eeac86..b497929 100644 --- a/docs/03-modules-organization/02-learning-goals.adoc +++ b/docs/03-distribution/02-learning-goals.adoc @@ -42,41 +42,83 @@ // 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 + +* 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 Buffers, 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 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 value and tradeoffs of imposing macro-architectural constraints across the organization. + +* Software architects understand the tradeoffs between using common modules across organizational units and "shared nothing" strategies. + +* Software architects can choose and implement 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[] diff --git a/docs/03-distribution/references.adoc b/docs/03-distribution/references.adoc new file mode 100644 index 0000000..d41679c --- /dev/null +++ b/docs/03-distribution/references.adoc @@ -0,0 +1,5 @@ +=== {references} + +<>, <>, <>, <>, <>, <>, <>, <> + + diff --git a/docs/03-modules-organization/references.adoc b/docs/03-modules-organization/references.adoc deleted file mode 100644 index 6b77de4..0000000 --- a/docs/03-modules-organization/references.adoc +++ /dev/null @@ -1,3 +0,0 @@ -=== {references} - -<>, <>, <>, <>, <> \ No newline at end of file diff --git a/docs/99-references/00-references.adoc b/docs/99-references/00-references.adoc index 8da1758..fed9693 100644 --- a/docs/99-references/00-references.adoc +++ b/docs/99-references/00-references.adoc @@ -10,6 +10,10 @@ Dieser Abschnitt enthält Quellenangaben, die ganz oder teilweise im Curriculum This section contains references that are cited in the curriculum. // end::EN[] +**A** + +- [[[architecturetvmanagement, Architektur im Stream]]] Software-Architektur im Stream:Architecture Management https://software-architektur.tv/tags.html#Architecture%20Management + **B** - [[[baxtersommerville,Baxter, Sommerville 2011]]] Gordon Baxter, Ian Sommerville: Sociotechnical Systems Design: Evolving Theory and Practice, 2011, https://academic.oup.com/iwc/article/23/1/4/693091 @@ -36,6 +40,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 +55,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. diff --git a/docs/config/setup.adoc b/docs/config/setup.adoc index fa05fa0..6ef31d7 100644 --- a/docs/config/setup.adoc +++ b/docs/config/setup.adoc @@ -17,7 +17,7 @@ :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 @@ -25,8 +25,8 @@ :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 diff --git a/docs/curriculum-flex.adoc b/docs/curriculum-flex.adoc index bb576b1..7b9c1b8 100644 --- a/docs/curriculum-flex.adoc +++ b/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}]