From 023e9fae39a3931709dc13a5a3f3ce8d409a3a1c Mon Sep 17 00:00:00 2001 From: Falk Sippach Date: Fri, 29 Nov 2024 17:32:52 +0100 Subject: [PATCH 01/20] #70 new chapter 3 added --- docs/03-integration/01-duration-terms.adoc | 8 ++--- .../03-modules-organization/00-structure.adoc | 18 ++++++++++ .../01-duration-terms.adoc | 17 ++++++++++ .../02-learning-goals.adoc | 34 +++++++++++++++++++ docs/03-modules-organization/references.adoc | 1 + docs/curriculum-flex.adoc | 2 +- 6 files changed, 73 insertions(+), 7 deletions(-) create mode 100644 docs/03-modules-organization/00-structure.adoc create mode 100644 docs/03-modules-organization/01-duration-terms.adoc create mode 100644 docs/03-modules-organization/02-learning-goals.adoc create mode 100644 docs/03-modules-organization/references.adoc diff --git a/docs/03-integration/01-duration-terms.adoc b/docs/03-integration/01-duration-terms.adoc index 1e240ab..035bffc 100644 --- a/docs/03-integration/01-duration-terms.adoc +++ b/docs/03-integration/01-duration-terms.adoc @@ -1,21 +1,17 @@ // tag::DE[] |=== -| Dauer: 90 Min. | Übungszeit: 30 Min. +| Dauer: 60 Min. | Übungszeit: 30 Min. |=== === Begriffe und Konzepte -Frontend Integration, Legacy Systeme, Authentifizierung, Autorisierung, (lose) Kopplung, Skalierbarkeit, Messaging Patterns, Domain Events, dezentrale Datenhaltung. // end::DE[] // tag::EN[] |=== -| Duration: 120 min | Practice time: 30 min +| Duration: 60 min | Practice time: 30 min |=== === Terms and Principles -Frontend integration, legacy systems, authentication, authorisation, -(loose) coupling, scalability, messaging patterns, domain events, -decentralised data management. // end::EN[] diff --git a/docs/03-modules-organization/00-structure.adoc b/docs/03-modules-organization/00-structure.adoc new file mode 100644 index 0000000..b729220 --- /dev/null +++ b/docs/03-modules-organization/00-structure.adoc @@ -0,0 +1,18 @@ +// header file for curriculum section 3: Lerneinheit 3 +// (c) iSAQB e.V. (https://isaqb.org) +// ==================================================== + +// tag::DE[] +== Softwaremodule und der Bezug zu Organisationsstrukturen +// end::DE[] + +// tag::EN[] +== Software Modules and the Organization +// end::EN[] + +include::01-duration-terms.adoc[{include_configuration}] + +include::02-learning-goals.adoc[{include_configuration}] + +// references (if any!) +include::references.adoc[{include_configuration}] diff --git a/docs/03-modules-organization/01-duration-terms.adoc b/docs/03-modules-organization/01-duration-terms.adoc new file mode 100644 index 0000000..035bffc --- /dev/null +++ b/docs/03-modules-organization/01-duration-terms.adoc @@ -0,0 +1,17 @@ +// tag::DE[] +|=== +| Dauer: 60 Min. | Übungszeit: 30 Min. +|=== + +=== Begriffe und Konzepte + +// end::DE[] + +// tag::EN[] +|=== +| Duration: 60 min | Practice time: 30 min +|=== + +=== Terms and Principles + +// end::EN[] diff --git a/docs/03-modules-organization/02-learning-goals.adoc b/docs/03-modules-organization/02-learning-goals.adoc new file mode 100644 index 0000000..5ecc1c6 --- /dev/null +++ b/docs/03-modules-organization/02-learning-goals.adoc @@ -0,0 +1,34 @@ +=== {learning-goals} + + +// tag::DE[] +[[LZ-3-1]] +==== LZ 3-1: Conway's Law anhand von Beispielen erklären + +Die Teilnehmenden sollen das Prinzip von Conway's Law verstehen und anhand praktischer Beispiele verdeutlichen können, wie die Kommunikationsstrukturen einer Organisation die Softwarearchitektur prägen. Ziel ist es, die Auswirkungen dieser Wechselwirkungen bewusst zu machen und für Architekturentscheidungen zu nutzen. + +[[LZ-3-2]] +==== LZ 3-2: Context Maps für Stakeholder Management nutzen + +Die Teilnehmenden lernen, Domain-Driven Design (DDD) Context Maps einzusetzen, um den aktuellen Zustand (AS-IS) und einen gewünschten zukünftigen Zustand (TO-BE) einer Systemlandschaft darzustellen. Dabei wird auch das Einbinden von Stakeholdern in den Veränderungsprozess thematisiert. Ziel ist es, Context Maps als Kommunikations- und Planungswerkzeug zu verstehen und anzuwenden. + + +[[LZ-3-3]] +==== LZ 3-3: Wechselwirkungen zwischen Organisation und Software Systemen erklären und analysieren + +Die Teilnehmenden sollen die bidirektionalen Einflüsse zwischen Organisationsstrukturen und Softwarearchitekturen verstehen und analysieren können. Dabei wird der Fokus darauf gelegt, wie organisatorische Änderungen Software beeinflussen und umgekehrt, um eine bessere Abstimmung zwischen beiden Welten zu erreichen. + +[[LZ-3-4]] +==== LZ 3-4: Begriffe wie Teamorganisation und sozio-technische Architekturen einordnen + +Die Teilnehmenden sollen Begriffe wie Team-Organisation, sozio-technische Architekturen und ähnliche Konzepte einordnen und deren Bedeutung im Kontext moderner Softwareentwicklung erklären können. Ziel ist es, ein Verständnis für die Verknüpfung technischer und sozialer Aspekte bei der Architekturgestaltung zu entwickeln. + +// end::DE[] + +// tag::EN[] +[[LG-3-1]] +==== LG 3-1: Explain Conway's Law using examples + +// end::EN[] + + diff --git a/docs/03-modules-organization/references.adoc b/docs/03-modules-organization/references.adoc new file mode 100644 index 0000000..da9242d --- /dev/null +++ b/docs/03-modules-organization/references.adoc @@ -0,0 +1 @@ +=== {references} diff --git a/docs/curriculum-flex.adoc b/docs/curriculum-flex.adoc index 5b7052d..235b5d1 100644 --- a/docs/curriculum-flex.adoc +++ b/docs/curriculum-flex.adoc @@ -47,7 +47,7 @@ include::01-motivation/00-structure.adoc[{include_configuration}] include::02-modularization/00-structure.adoc[{include_configuration}] <<< -include::03-integration/00-structure.adoc[{include_configuration}] +include::03-modules-organization/00-structure.adoc[{include_configuration}] <<< include::04-rollout/00-structure.adoc[{include_configuration}] From 18692ac7618d5b62f255f998b33a1a44035e8f5e Mon Sep 17 00:00:00 2001 From: Falk Sippach Date: Fri, 29 Nov 2024 18:37:02 +0100 Subject: [PATCH 02/20] #71: moved chapter 3 (integration) to 4, shortened text --- docs/03-integration/02-learning-goals.adoc | 206 ------------------ .../00-structure.adoc | 4 +- .../01-duration-terms.adoc | 0 docs/04-integration/02-learning-goals.adoc | 79 +++++++ .../references.adoc | 0 docs/curriculum-flex.adoc | 2 +- 6 files changed, 82 insertions(+), 209 deletions(-) delete mode 100644 docs/03-integration/02-learning-goals.adoc rename docs/{03-integration => 04-integration}/00-structure.adoc (84%) rename docs/{03-integration => 04-integration}/01-duration-terms.adoc (100%) create mode 100644 docs/04-integration/02-learning-goals.adoc rename docs/{03-integration => 04-integration}/references.adoc (100%) diff --git a/docs/03-integration/02-learning-goals.adoc b/docs/03-integration/02-learning-goals.adoc deleted file mode 100644 index 75cc7d7..0000000 --- a/docs/03-integration/02-learning-goals.adoc +++ /dev/null @@ -1,206 +0,0 @@ -=== {learning-goals} - -// tag::DE[] -[[LZ-3-1]] -==== LZ 3-1: Strategic Design - -1. Die Teilnehmer sollen ein grundlegendes Verständnis für die Umsetzung von Integrationen mithilfe von Strategic Design aus dem Domain Driven Design und den wesentliche Pattern (bspw. Customer/Supplier) anwenden können. Ziel ist, dass die Teilnehmer die Auswirkungen von Beziehungen zwischen Systemen anhand einer Context Map darstellen und SOLL/IST-Vergleiche erstellen können, die als Entscheidungskriterien für Team-Setup und Organisations-Architektur nutzbar sind. -2. Für die Integration von Legacy-Systemen muss definiert werden, wie mit alten Datenmodellen umgegangen wird. Dazu kann der Ansatz des Strategic Designs mit wesentlichen Patterns wie beispielsweise Anti-Corruption Layer genutzt werden. - - - -[[LZ-3-2]] -==== LZ 3-2: Technische Integrations-Strategie wählen - -. Die Teilnehmer sollen die Vor- und Nachteile verschiedener Integrationsmechanismen kennen. Dazu zählen Frontend-Integration mit Mash Ups, Integration auf dem Middle Tier und Integration über Datenbanken oder Datenbank-Replikation. -. Die Teilnehmer können abhängig von den Qualitätszielen und dem Wissen des Teams eine geeignete Integration vorschlagen. -. Die Teilnehmer sollen eine Integrationsstrategie wählen, die auf das jeweilige Problem am besten passt. Das kann beispielsweise eine Frontend-Integration, eine Integration über RPC-Mechanismen, mit Message-orientierter Middleware, mit REST oder über die Replikation von Daten sein. -. Teilnehmer verstehen, dass eine Integrationsstrategie darüber entscheidet, ob eine Abhängigkeit -** erst zur Laufzeit entsteht, -** zur Entwicklungszeit entsteht oder -** beim Deployment entsteht. -. Die Teilnehmer sollen die Konsequenzen und Einschränkungen verstehen, die sich aus der Integration von Systemen über verschiedenen Technologien und Integrationsmuster z. B. in Bezug auf Sicherheit, Antwortzeit oder Latenz ergeben. -. Die Teilnehmer sollten verstehen, dass Messaging Kopplung an das -Datenformat oder an eine API bedingt. REST macht Vorgaben, die diese -Kopplung reduzieren können (Hypermedia, standardisierte API). -. Die Teilnehmer sollten verstehen, dass synchrone Kommunikation, zum -Beispiel durch RPC, zeitliche Kopplung bedingt. Asynchrone -Kommunikation ermöglicht, diese Kopplung aufzuweichen und erlaubt -unter Umständen, dass ein System den Request oder die Berechnung -weiter bearbeiten kann, ohne dass die -asynchron an Backend-Systeme geschickten Anfragen bereits von diesen -beantwortet wurden. -Entkopplung lässt sich -außerdem durch selektives Kommunikation erreichen. -. Die Teilnehmer verstehen, dass bei der Verwendung von Messaging -und der Kommunikation mit anderen Systemen im Vergleich zum Aufruf -lokaler Funktionen Verfügbarkeit und -Antwortzeiten des Systems beeinträchtigt werden können. -. Die Teilnehmer wissen, dass es für Messaging sogenannte -Message-Oriented Middleware gibt, die bestimmte Garantien gibt -und der Entwickler:in viele Aufgaben erleichtert. Nachrichten können optional -persistiert, gefiltert, transformiert etc. werden. Es gibt -verschiedene Messaging-Patterns wie Request/Reply, Publish/Subscribe -oder Broadcast. -. Eine Integration über Daten ermöglicht hohe Autonomie, die allerdings über die Notwendigkeit zur redundanten Datenhaltung und die damit notwendige Synchronisation erkauft wird. Es darf nicht angenommen werden, dass andere Systeme dieselben Schemata nutzen, weil das eine unabhängige Weiterentwicklung der Schemata verhindert. Daher muss für die Integration eine angemessene Transformation vorgesehen werden. -. Die Teilnehmer sollen verschiedene Ansätze für die Frontend-Integration sowie deren Vor- und Nachteile und Anwendbarkeit abhängig von Kontextkriterien benennen können. -. Die Teilnehmer sollen Techniken für die Integration von Services: REST, RPC, Message-orientierte Middleware kennen. -. Die Teilnehmer sollen Datenbank-Replikationsmechanismen mit ETL-Tools oder anderen Ansätzen kennen. -. Die Teilnehmer sollen Messaging Patterns (Request/Reply, Publish/Subscribe etc.) kennen. -. Die Teilnehmer sollen Messaging Systeme (RabbitMQ, Kafka, etc.), Protokolle (AMQP, MQTT, STOMP, etc.) und APIs (JMS) kennen. - -[[LZ-3-3]] -==== LZ 3-3: Makroarchitektur erläutern und Kriterien aufstellen können - -. Anhand dieser Ansätze sollen die Teilnehmer eine Makroarchitektur entwerfen können, die zumindest Kommunikation und Sicherheit abdeckt. -. Die Teilnehmer können klare Kriterien benennen anhand derer Entwickler selbständig herausfinden, ob eine (Architektur-)Entscheidung ein Mikro- oder eine Makroarchitektur Entscheidung ist resp. ob sie die Entscheidung allein treffen können oder team-externe Stakeholder in den Entscheidungsprozess einbeziehen müssen - - -[[LZ-3-4]] -==== LZ 3-4: Domain Events statt RPC für die Integration von Bounded Contexts - -. Bei einer Event-Driven Architecture (EDA) werden Remote Procedure Calls (RPC) vermieden oder reduziert, indem Domain Events (vgl. DDD Curriculum) publiziert werden. Domain Events beschreiben Zustandsänderungen. Interessierte Systeme können diese Nachrichten verarbeiten (Publish/Subscribe). Dieses Vorgehen hat Auswirkungen darauf, wie der Zustand gespeichert wird. Während bei einer RPC-basierten Integration der Server die Daten speichern muss, liegt diese Verantwortung bei EDA beim Subscriber. Somit entstehen Replikate (dezentrale Datenhaltung). Die Subscriber fungieren dadurch als Cache für den Publisher. Es können weitere Subscriber hinzugefügt werden, ohne den Publisher zu beeinflussen (außer durch Polling). Monitoring der Event-Flüsse ist wichtig. -. Domain Events können via Messaging publiziert werden. Dabei pusht der Publisher die Nachrichten in ein Messaging System. Alternativ können die Nachrichten auch beim Publisher gepollt werden (bspw. Atom/RSS). Beim Einsatz eines Messaging Systems können Subscriber die Nachrichten per Push oder Pull erhalten. Dies hat Auswirkungen auf den Umgang mit Backpressure. -. Die Teilnehmer sollen Herausforderungen bei der Nutzung gemeinsamer Daten kennen. - - - -[[LZ-3-5]] -==== LZ 3-5: Sicherheit - -. Die Teilnehmer sollen einen geeigneten Ansatz für das Umsetzen von Sicherheit (Autorisierung/Authentifizierung) in einem verteilten System konzeptionieren können. -. Die Teilnehmer sollen typische verteilte Sicherheitsmechanismen wie OAuth2, OpenID Connect, SAML oder Kerberos kennen und deren Flows erläutern können. - -// end::DE[] - -// tag::EN[] -[[LG-3-1]] -==== LG 3-1: Strategic Design - -1. Participants should have a basic understanding of the - implementation of integrations using Strategic Design from Domain - Driven Design and know fundamental patterns. - -2. For the integration of legacy systems, it has to be defined how to - handle old data models. For this purpose, the approach of strategic - design can be used with essential patterns such as anti-corruption - layers. - - -[[LG-3-2]] -==== LG 3-2: Choosing a technical integration strategy - -. The participants should know the benefits and drawbacks of different - integration mechanisms. These include front-end integration with - Mash Ups, Middle Tier integration, and integration through databases - or database replication. - -. The participants can propose a suitable integration depending on the - quality goals and the knowledge of the team. - -. The participants should choose an integration strategy that best - suits the particular problem. This can be, for example, front-end - integration, integration via RPC mechanisms, message-oriented - middleware, REST, or replication of data. - -. Participants understand that an integration strategy determines - whether a dependency -** forms only at runtime, -** forms at development time, or -** forms during deployment. - -. Participants should understand the implications and limitations that - arise from the integration of systems across different technologies - and integration patterns, relating to, for example, security, - response time, or latency. - -. The participants should understand that messaging implies coupling - through the data format or an API. REST contains conventions that - can reduce this coupling (hypermedia, standardised API). - -. The participants should understand that that synchronous - communication, for example through RPC, implies temporal coupling. - Asynchronous communication enables loosening this coupling and may - enable the system to continue to process a request or a - computation, even though the requests asynchronously sent to - backend systems have not been answered yet. Decoupling can also be - achieved through selective communication. - -. With integrating through messaging, systems communicate through the - asynchronous exchange of messages. The systems are thus decoupled in - time. Technically, this is achieved by means of indirection via a - middleware. Messages can optionally be persisted, filtered, - transformed, etc. There are different messaging patterns like - Request / Reply, Publish / Subscribe or Broadcast. - -. An integration via data enables high autonomy, nevertheless it is - bought by the necessity for redundant data storage and the necessary - synchronisation. It must not be assumed that other systems use the - same schemes, because this prevents an independent development of - the schemata. Therefore, an adequate transformation has to be - provided for the integration. - -. The participants should be able to name different approaches for - front-end integration as well as their benefits and drawbacks and - applicability according to context criteria. - -. The participants should know technologies for the integration of - services: REST, RPC, message-oriented middleware. - -. The participants should know database replication mechanisms using - ETL tools or other approaches - -. The participants should know messaging Patterns (Request / Reply, - Publish / Subscribe, etc.) - -. The participants should know messaging systems (RabbitMQ, Kafka - etc.), protocols (AMQP, MQTT, STOMP etc.) and APIs (JMS). - -[[LG-3-3]] -==== LG 3-3: Explain macro architecture und formulate criteria - -. Based on these approaches, participants should be able to design a - macro architecture that covers at least communication and security. - -. The participants can name clear criteria developers can use - independently to determine if an (architecture) decision is a - decision about micro architecture or macro architecture, if they can - make that decision on their own or if they need to involve external - stakeholders in the decision process. - -[[LG-3-4]] -==== LG 3-4: Domain events instead of RPC for integrating bounded contexts - -. In an event-driven architecture (EDA), RPC is avoided or reduced by - publishing domain events. Domain events describe state - changes. Interested systems can process these messages (Publish / - Subscribe). This procedure affects how the state is stored. While, - in an RPC-based integration the server has to store the data, with - EDA this is the responsibility of the subscriber. Thus, replicas - arise (decentralised data storage). Thereby, the subscribers act as - a cache for the publisher. Additional subscribers can be added - without affecting the publisher (except by polling). Monitoring of - the event flows is important. - -. Domain events can be published via messaging. The publisher pushes - the messages into a messaging system. Alternatively, the messages - can be polled from the publisher (e.g., Atom / RSS). When using a - messaging system, subscribers can receive the messages by push or - pull. This has implications for dealing with backpressure. - - -. The participants should know challenges of the usage of shared data. - -[[LG-3-5]] -==== LG 3-5: Security - -. Participants should be able to design a suitable approach for - implementing security (authorisation / authentication) in a - distributed system. - -. The participants should know typical distributed security mechanisms - such as OAuth or Kerberos - -// end::EN[] - - diff --git a/docs/03-integration/00-structure.adoc b/docs/04-integration/00-structure.adoc similarity index 84% rename from docs/03-integration/00-structure.adoc rename to docs/04-integration/00-structure.adoc index e514fed..e5d1b9f 100644 --- a/docs/03-integration/00-structure.adoc +++ b/docs/04-integration/00-structure.adoc @@ -3,11 +3,11 @@ // ==================================================== // tag::DE[] -== Integration +== Integrationsmethoden & Protokolle // end::DE[] // tag::EN[] -== Integration +== Integration methods & protocols // end::EN[] include::01-duration-terms.adoc[{include_configuration}] diff --git a/docs/03-integration/01-duration-terms.adoc b/docs/04-integration/01-duration-terms.adoc similarity index 100% rename from docs/03-integration/01-duration-terms.adoc rename to docs/04-integration/01-duration-terms.adoc diff --git a/docs/04-integration/02-learning-goals.adoc b/docs/04-integration/02-learning-goals.adoc new file mode 100644 index 0000000..f0ffd59 --- /dev/null +++ b/docs/04-integration/02-learning-goals.adoc @@ -0,0 +1,79 @@ +=== {learning-goals} + +// tag::DE[] +[[LZ-4-1]] +==== LZ 4-1: Integrationsstrategien gegenüberstellen (am Beispiel von DDD Strategic Design) + +* Verstehen von Strategic Design aus dem Domain-Driven Design (DDD) für die Integration (z. B. Anti-Corruption Layer, Shared Kernel, Bounded Context). +* Bewertung der Vor- und Nachteile von Integrationsansätzen wie REST, Messaging oder Datenbankintegration anhand spezifischer Qualitätsziele. +* Einsatz von Frontend-Integration und Middleware für Legacy-Systeme. +* Praktische Anwendung: Integration alter Datenmodelle durch Transformation und Mapping. + +[[LZ-4-2]] +==== LZ 4-2: Konsistenzmodelle erklären und auswählen (CAP Theorem) + +* Erklärung des CAP-Theorems: Abwägung zwischen Konsistenz, Verfügbarkeit und Partitionstoleranz. +* Vergleich von ACID- und BASE-Modellen: Einsatzmöglichkeiten in verteilten Systemen. +* Praxisbeispiel: Wahl eines geeigneten Konsistenzmodells basierend auf Systemanforderungen wie Latenz und Skalierbarkeit. + +[[LZ-4-3]] +==== LZ 4-3: Resilience Patterns benennen + +* Messaging Patterns: Request/Reply, Publish/Subscribe und deren Resilience-Eigenschaften. +* Resilience-Strategien für dezentrale Datenhaltung und redundante Architektur. +* Nutzung von Mechanismen wie Circuit Breaker, Graceful Degradation und Bulkhead zur Sicherstellung der Verfügbarkeit. + +[[LZ-4-4]] +==== LZ 4-4: Sicherheitsauswirkungen von Integrationsmethoden kennen und berücksichtigen + +* Vergleich von Authentifizierungs- und Autorisierungsmechanismen (z. B. OAuth, Kerberos). +* Auswirkungen von synchroner (z. B. RPC) vs. asynchroner Integration (z. B. Messaging) auf Sicherheit und Datenintegrität. +* Implementierung sicherer Schnittstellen und Makroarchitektur für verteilte Systeme. + +[[LZ-4-5]] +==== LZ 4-5: (OPTIONAL) Event-getriebene Architekturen kennen und entwerfen + +* Einführung in Event-Driven Architectures (EDA): Publizieren von Domain Events zur Entkopplung von Systemen. +* Entwurf einer EDA mit Messaging-Systemen wie RabbitMQ oder Kafka. +* Herausforderungen und Lösungen bei Backpressure und dezentraler Datenhaltung. + +// end::DE[] + +// tag::EN[] + +[[LG-4-1]] +==== LG 4-1: Compare Integration Strategies (using DDD Strategic Design as an example) + +* Understand Strategic Design from Domain-Driven Design (DDD) for integration (e.g., Anti-Corruption Layer, Shared Kernel, Bounded Context). +* Evaluate the pros and cons of integration approaches like REST, Messaging, or Database Integration based on specific quality goals. +* Utilize Frontend Integration and Middleware for legacy systems. +Practical application: Integrate old data models through transformation and mapping. + +[[LG-4-2]] +==== LG 4-2: Explain and Select Consistency Models (CAP Theorem) + +* Explain the CAP Theorem: Trade-offs between Consistency, Availability, and Partition Tolerance. +* Compare ACID and BASE models: Use cases in distributed systems. +* Practical example: Choosing an appropriate consistency model based on system requirements like latency and scalability. + +[[LG-4-3]] +==== LG 4-3: Identify Resilience Patterns +* Messaging Patterns: Request/Reply, Publish/Subscribe, and their resilience properties. +* Resilience Strategies for decentralized data storage and redundant architectures. +* Use mechanisms like Circuit Breaker, Graceful Degradation, and Bulkhead to ensure availability. + +[[LG-4-4]] +==== LG 4-4: Understand and Consider Security Impacts of Integration Methods + +* Compare Authentication and Authorization mechanisms (e.g., OAuth, Kerberos). +* Explore the security and data integrity implications of synchronous (e.g., RPC) vs. asynchronous integration (e.g., Messaging). +* Implement secure interfaces and macro-architectures for distributed systems. + +[[LG-4-5]] +==== LG 4-5: (OPTIONAL) Understand and Design Event-Driven Architectures + +* Introduction to Event-Driven Architectures (EDA): Publishing Domain Events to decouple systems. +* Design an EDA using messaging systems like RabbitMQ or Kafka. +* Address challenges and solutions for Backpressure and decentralized data storage. + +// end::EN[] diff --git a/docs/03-integration/references.adoc b/docs/04-integration/references.adoc similarity index 100% rename from docs/03-integration/references.adoc rename to docs/04-integration/references.adoc diff --git a/docs/curriculum-flex.adoc b/docs/curriculum-flex.adoc index 5b7052d..2ae72ce 100644 --- a/docs/curriculum-flex.adoc +++ b/docs/curriculum-flex.adoc @@ -47,7 +47,7 @@ include::01-motivation/00-structure.adoc[{include_configuration}] include::02-modularization/00-structure.adoc[{include_configuration}] <<< -include::03-integration/00-structure.adoc[{include_configuration}] +include::04-integration/00-structure.adoc[{include_configuration}] <<< include::04-rollout/00-structure.adoc[{include_configuration}] From 0ef865bebd8610cbc946b8427887e014558c60b0 Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sat, 30 Nov 2024 23:18:55 +0100 Subject: [PATCH 03/20] Update docs/04-integration/02-learning-goals.adoc --- docs/04-integration/02-learning-goals.adoc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/04-integration/02-learning-goals.adoc b/docs/04-integration/02-learning-goals.adoc index f0ffd59..0443e12 100644 --- a/docs/04-integration/02-learning-goals.adoc +++ b/docs/04-integration/02-learning-goals.adoc @@ -4,7 +4,9 @@ [[LZ-4-1]] ==== LZ 4-1: Integrationsstrategien gegenüberstellen (am Beispiel von DDD Strategic Design) -* Verstehen von Strategic Design aus dem Domain-Driven Design (DDD) für die Integration (z. B. Anti-Corruption Layer, Shared Kernel, Bounded Context). +* Strategic Design aus dem Domain-Driven Design (DDD) und dessen Beziehungspatterns (z. B. Anti-Corruption Layer, Shared Kernel, Customer/Supplier) verstehen und erklären +* Modulgrenzen eines Systems anhand von "Bounded Context" darstellen, beschreiben und SOLL/IST-Vergleiche anstellen +* Anhand der Qualitätsziele begründen welche Patterns aus dem Strategic Design für eine Integration/Schnittstelle verwendet werden können und welche Patterns nicht * Bewertung der Vor- und Nachteile von Integrationsansätzen wie REST, Messaging oder Datenbankintegration anhand spezifischer Qualitätsziele. * Einsatz von Frontend-Integration und Middleware für Legacy-Systeme. * Praktische Anwendung: Integration alter Datenmodelle durch Transformation und Mapping. From ffe326e1a382bd0cb53806fb132e62e0faf6cb42 Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sat, 30 Nov 2024 23:19:01 +0100 Subject: [PATCH 04/20] Update docs/04-integration/02-learning-goals.adoc --- docs/04-integration/02-learning-goals.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/04-integration/02-learning-goals.adoc b/docs/04-integration/02-learning-goals.adoc index 0443e12..2ff75a9 100644 --- a/docs/04-integration/02-learning-goals.adoc +++ b/docs/04-integration/02-learning-goals.adoc @@ -8,7 +8,7 @@ * Modulgrenzen eines Systems anhand von "Bounded Context" darstellen, beschreiben und SOLL/IST-Vergleiche anstellen * Anhand der Qualitätsziele begründen welche Patterns aus dem Strategic Design für eine Integration/Schnittstelle verwendet werden können und welche Patterns nicht * Bewertung der Vor- und Nachteile von Integrationsansätzen wie REST, Messaging oder Datenbankintegration anhand spezifischer Qualitätsziele. -* Einsatz von Frontend-Integration und Middleware für Legacy-Systeme. +* (OPTIONAL) Frontend-Integration (Links, Client-Side Includes, Microfrontends, etc.) und Middleware für Legacy-Systeme sowie deren Auswirkungen vergleichen * Praktische Anwendung: Integration alter Datenmodelle durch Transformation und Mapping. [[LZ-4-2]] From 2119f82fe2b3459515f0cebae867c818ff0034e1 Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sat, 30 Nov 2024 23:19:07 +0100 Subject: [PATCH 05/20] Update docs/04-integration/02-learning-goals.adoc --- docs/04-integration/02-learning-goals.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/04-integration/02-learning-goals.adoc b/docs/04-integration/02-learning-goals.adoc index 2ff75a9..17c313e 100644 --- a/docs/04-integration/02-learning-goals.adoc +++ b/docs/04-integration/02-learning-goals.adoc @@ -9,7 +9,7 @@ * Anhand der Qualitätsziele begründen welche Patterns aus dem Strategic Design für eine Integration/Schnittstelle verwendet werden können und welche Patterns nicht * Bewertung der Vor- und Nachteile von Integrationsansätzen wie REST, Messaging oder Datenbankintegration anhand spezifischer Qualitätsziele. * (OPTIONAL) Frontend-Integration (Links, Client-Side Includes, Microfrontends, etc.) und Middleware für Legacy-Systeme sowie deren Auswirkungen vergleichen -* Praktische Anwendung: Integration alter Datenmodelle durch Transformation und Mapping. +* (OPTIONAL) Praktische Anwendung in brow-field Szenarien: Integration von Legacy-Datenmodellen durch Transformation und Mapping. [[LZ-4-2]] ==== LZ 4-2: Konsistenzmodelle erklären und auswählen (CAP Theorem) From 0391dac05a9c501b3e51fcf539a7e476e3eff887 Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sat, 30 Nov 2024 23:19:14 +0100 Subject: [PATCH 06/20] Update docs/04-integration/02-learning-goals.adoc --- docs/04-integration/02-learning-goals.adoc | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/04-integration/02-learning-goals.adoc b/docs/04-integration/02-learning-goals.adoc index 17c313e..4960c9a 100644 --- a/docs/04-integration/02-learning-goals.adoc +++ b/docs/04-integration/02-learning-goals.adoc @@ -15,7 +15,11 @@ ==== LZ 4-2: Konsistenzmodelle erklären und auswählen (CAP Theorem) * Erklärung des CAP-Theorems: Abwägung zwischen Konsistenz, Verfügbarkeit und Partitionstoleranz. -* Vergleich von ACID- und BASE-Modellen: Einsatzmöglichkeiten in verteilten Systemen. +* Notwendigkeit von Partitionstoleranz verstehen +* Vergleich von ACID- und BASE-Modellen: Garantien, Verluste und Tradeoffs sowie daraus resultierende Einsatzmöglichkeiten in verteilten Systemen verstehen +* Unterschied zwischen "Consistency" bei ACID und BASE anhand praktischer Beispiele erklären +* (OPTIONAL) Praxisbeispiel zu ACID-Transaktionen und BASE-Transaktionen in verteilten Systemen +* CP- vs. AP-Systemdesign anhand von Qualitätszielen begründen * Praxisbeispiel: Wahl eines geeigneten Konsistenzmodells basierend auf Systemanforderungen wie Latenz und Skalierbarkeit. [[LZ-4-3]] From 9fc42f38052a922e0a18e0a4ef8a21888084f826 Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sat, 30 Nov 2024 23:19:26 +0100 Subject: [PATCH 07/20] Update docs/04-integration/02-learning-goals.adoc --- docs/04-integration/02-learning-goals.adoc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/04-integration/02-learning-goals.adoc b/docs/04-integration/02-learning-goals.adoc index 4960c9a..9fcbc68 100644 --- a/docs/04-integration/02-learning-goals.adoc +++ b/docs/04-integration/02-learning-goals.adoc @@ -7,7 +7,10 @@ * Strategic Design aus dem Domain-Driven Design (DDD) und dessen Beziehungspatterns (z. B. Anti-Corruption Layer, Shared Kernel, Customer/Supplier) verstehen und erklären * Modulgrenzen eines Systems anhand von "Bounded Context" darstellen, beschreiben und SOLL/IST-Vergleiche anstellen * Anhand der Qualitätsziele begründen welche Patterns aus dem Strategic Design für eine Integration/Schnittstelle verwendet werden können und welche Patterns nicht -* Bewertung der Vor- und Nachteile von Integrationsansätzen wie REST, Messaging oder Datenbankintegration anhand spezifischer Qualitätsziele. +[[LZ-4-2]] + ==== LZ 4-2: Technische Integrationsmechanismen auswählen und begründen + + * Bewertung der Vor- und Nachteile von technischen Integrationsmechanismen wie Frontend-Integration, Middle-Tier Integration (REST, RPC, Messaging) oder Datenbankintegration anhand spezifischer Qualitätsziele des System und notwendiger Erfahrung/Skills der betreuenden Entwicklungsteams. * (OPTIONAL) Frontend-Integration (Links, Client-Side Includes, Microfrontends, etc.) und Middleware für Legacy-Systeme sowie deren Auswirkungen vergleichen * (OPTIONAL) Praktische Anwendung in brow-field Szenarien: Integration von Legacy-Datenmodellen durch Transformation und Mapping. From e8d6d76d72a0cd00c5881248a0ea24e53e5a569b Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sat, 30 Nov 2024 23:19:45 +0100 Subject: [PATCH 08/20] Update docs/04-integration/02-learning-goals.adoc --- docs/04-integration/02-learning-goals.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/04-integration/02-learning-goals.adoc b/docs/04-integration/02-learning-goals.adoc index 9fcbc68..c7c2164 100644 --- a/docs/04-integration/02-learning-goals.adoc +++ b/docs/04-integration/02-learning-goals.adoc @@ -26,7 +26,7 @@ * Praxisbeispiel: Wahl eines geeigneten Konsistenzmodells basierend auf Systemanforderungen wie Latenz und Skalierbarkeit. [[LZ-4-3]] -==== LZ 4-3: Resilience Patterns benennen +==== LZ 4-4: Resilience Patterns benennen * Messaging Patterns: Request/Reply, Publish/Subscribe und deren Resilience-Eigenschaften. * Resilience-Strategien für dezentrale Datenhaltung und redundante Architektur. From 97d3f7922f8ec695e522b26c817d522248d8e177 Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sat, 30 Nov 2024 23:19:51 +0100 Subject: [PATCH 09/20] Update docs/04-integration/02-learning-goals.adoc --- docs/04-integration/02-learning-goals.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/04-integration/02-learning-goals.adoc b/docs/04-integration/02-learning-goals.adoc index c7c2164..a02cf79 100644 --- a/docs/04-integration/02-learning-goals.adoc +++ b/docs/04-integration/02-learning-goals.adoc @@ -32,7 +32,7 @@ * Resilience-Strategien für dezentrale Datenhaltung und redundante Architektur. * Nutzung von Mechanismen wie Circuit Breaker, Graceful Degradation und Bulkhead zur Sicherstellung der Verfügbarkeit. -[[LZ-4-4]] +[[LZ-4-5]] ==== LZ 4-4: Sicherheitsauswirkungen von Integrationsmethoden kennen und berücksichtigen * Vergleich von Authentifizierungs- und Autorisierungsmechanismen (z. B. OAuth, Kerberos). From 39d99aa8b454d29ffe25aece20aa0c9f46ac80fe Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sat, 30 Nov 2024 23:19:58 +0100 Subject: [PATCH 10/20] Update docs/04-integration/02-learning-goals.adoc --- docs/04-integration/02-learning-goals.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/04-integration/02-learning-goals.adoc b/docs/04-integration/02-learning-goals.adoc index a02cf79..b2218d9 100644 --- a/docs/04-integration/02-learning-goals.adoc +++ b/docs/04-integration/02-learning-goals.adoc @@ -33,7 +33,7 @@ * Nutzung von Mechanismen wie Circuit Breaker, Graceful Degradation und Bulkhead zur Sicherstellung der Verfügbarkeit. [[LZ-4-5]] -==== LZ 4-4: Sicherheitsauswirkungen von Integrationsmethoden kennen und berücksichtigen +==== LZ 4-5: Sicherheitsauswirkungen von Integrationsmethoden kennen und berücksichtigen * Vergleich von Authentifizierungs- und Autorisierungsmechanismen (z. B. OAuth, Kerberos). * Auswirkungen von synchroner (z. B. RPC) vs. asynchroner Integration (z. B. Messaging) auf Sicherheit und Datenintegrität. From c5e77802c5aa9a9fd9aa945e597ac079a821d908 Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sat, 30 Nov 2024 23:20:05 +0100 Subject: [PATCH 11/20] Update docs/04-integration/02-learning-goals.adoc --- docs/04-integration/02-learning-goals.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/04-integration/02-learning-goals.adoc b/docs/04-integration/02-learning-goals.adoc index b2218d9..9de9984 100644 --- a/docs/04-integration/02-learning-goals.adoc +++ b/docs/04-integration/02-learning-goals.adoc @@ -39,7 +39,7 @@ * Auswirkungen von synchroner (z. B. RPC) vs. asynchroner Integration (z. B. Messaging) auf Sicherheit und Datenintegrität. * Implementierung sicherer Schnittstellen und Makroarchitektur für verteilte Systeme. -[[LZ-4-5]] +[[LZ-4-6]] ==== LZ 4-5: (OPTIONAL) Event-getriebene Architekturen kennen und entwerfen * Einführung in Event-Driven Architectures (EDA): Publizieren von Domain Events zur Entkopplung von Systemen. From ef1cb5bea6b2a96ec8ba68b7f66d6588427263fa Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sat, 30 Nov 2024 23:20:16 +0100 Subject: [PATCH 12/20] Update docs/04-integration/02-learning-goals.adoc --- docs/04-integration/02-learning-goals.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/04-integration/02-learning-goals.adoc b/docs/04-integration/02-learning-goals.adoc index 9de9984..aba25cc 100644 --- a/docs/04-integration/02-learning-goals.adoc +++ b/docs/04-integration/02-learning-goals.adoc @@ -40,7 +40,7 @@ * Implementierung sicherer Schnittstellen und Makroarchitektur für verteilte Systeme. [[LZ-4-6]] -==== LZ 4-5: (OPTIONAL) Event-getriebene Architekturen kennen und entwerfen +==== LZ 4-6: (OPTIONAL) Event-getriebene Architekturen kennen und entwerfen * Einführung in Event-Driven Architectures (EDA): Publizieren von Domain Events zur Entkopplung von Systemen. * Entwurf einer EDA mit Messaging-Systemen wie RabbitMQ oder Kafka. From d3be5563645a3a423b6942da46e4eb03362e8144 Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sat, 30 Nov 2024 23:51:25 +0100 Subject: [PATCH 13/20] Integrated review comments and translation --- docs/04-integration/02-learning-goals.adoc | 97 +++++++++++++--------- html-theme | 2 +- pdf-theme | 2 +- 3 files changed, 59 insertions(+), 42 deletions(-) diff --git a/docs/04-integration/02-learning-goals.adoc b/docs/04-integration/02-learning-goals.adoc index aba25cc..885552f 100644 --- a/docs/04-integration/02-learning-goals.adoc +++ b/docs/04-integration/02-learning-goals.adoc @@ -4,38 +4,41 @@ [[LZ-4-1]] ==== LZ 4-1: Integrationsstrategien gegenüberstellen (am Beispiel von DDD Strategic Design) -* Strategic Design aus dem Domain-Driven Design (DDD) und dessen Beziehungspatterns (z. B. Anti-Corruption Layer, Shared Kernel, Customer/Supplier) verstehen und erklären -* Modulgrenzen eines Systems anhand von "Bounded Context" darstellen, beschreiben und SOLL/IST-Vergleiche anstellen -* Anhand der Qualitätsziele begründen welche Patterns aus dem Strategic Design für eine Integration/Schnittstelle verwendet werden können und welche Patterns nicht +* Strategic Design aus dem Domain-Driven Design (DDD) und dessen Beziehungspatterns (z. B. Anti-Corruption Layer, Shared Kernel, Customer/Supplier) verstehen und erklären. +* Modulgrenzen eines Systems anhand von "Bounded Context" darstellen, beschreiben und SOLL/IST-Vergleiche anstellen. +* Anhand der Qualitätsziele begründen welche Patterns aus dem Strategic Design für eine Integration/Schnittstelle verwendet werden können und welche Patterns nicht. + [[LZ-4-2]] - ==== LZ 4-2: Technische Integrationsmechanismen auswählen und begründen +==== LZ 4-2: Technische Integrationsmechanismen auswählen und begründen - * Bewertung der Vor- und Nachteile von technischen Integrationsmechanismen wie Frontend-Integration, Middle-Tier Integration (REST, RPC, Messaging) oder Datenbankintegration anhand spezifischer Qualitätsziele des System und notwendiger Erfahrung/Skills der betreuenden Entwicklungsteams. -* (OPTIONAL) Frontend-Integration (Links, Client-Side Includes, Microfrontends, etc.) und Middleware für Legacy-Systeme sowie deren Auswirkungen vergleichen +* Bewertung der Vor- und Nachteile von technischen Integrationsmechanismen wie Frontend-Integration, Middle-Tier Integration (REST, RPC, Messaging) oder Datenbankintegration anhand spezifischer Qualitätsziele des System und notwendiger Erfahrung/Skills der betreuenden Entwicklungsteams. +* (OPTIONAL) Frontend-Integration (Links, Client-Side Includes, Microfrontends, etc.) und Middleware für Legacy-Systeme sowie deren Auswirkungen vergleichen. * (OPTIONAL) Praktische Anwendung in brow-field Szenarien: Integration von Legacy-Datenmodellen durch Transformation und Mapping. -[[LZ-4-2]] -==== LZ 4-2: Konsistenzmodelle erklären und auswählen (CAP Theorem) +[[LZ-4-3]] +==== LZ 4-3: Konsistenzmodelle erklären und auswählen (CAP Theorem) * Erklärung des CAP-Theorems: Abwägung zwischen Konsistenz, Verfügbarkeit und Partitionstoleranz. -* Notwendigkeit von Partitionstoleranz verstehen -* Vergleich von ACID- und BASE-Modellen: Garantien, Verluste und Tradeoffs sowie daraus resultierende Einsatzmöglichkeiten in verteilten Systemen verstehen -* Unterschied zwischen "Consistency" bei ACID und BASE anhand praktischer Beispiele erklären -* (OPTIONAL) Praxisbeispiel zu ACID-Transaktionen und BASE-Transaktionen in verteilten Systemen -* CP- vs. AP-Systemdesign anhand von Qualitätszielen begründen -* Praxisbeispiel: Wahl eines geeigneten Konsistenzmodells basierend auf Systemanforderungen wie Latenz und Skalierbarkeit. - -[[LZ-4-3]] +* Notwendigkeit von Partitionstoleranz verstehen. +* Vergleich von ACID- und BASE-Modellen: Garantien, Verluste und Tradeoffs sowie daraus resultierende Einsatzmöglichkeiten in verteilten Systemen verstehen. +* Unterschied zwischen "Consistency" bei ACID und BASE anhand praktischer Beispiele erklären. +* (OPTIONAL) Praxisbeispiel zu ACID-Transaktionen und BASE-Transaktionen in verteilten Systemen. +* CP- vs. AP-Systemdesign anhand von Qualitätszielen begründen. +* (OPTIONAL) Praxisbeispiel: Wahl eines geeigneten Konsistenzmodells basierend auf Systemanforderungen wie Latenz und Skalierbarkeit. +* (OPTIONAL) Produktbeispiele aus unterschiedlichen Kategorien (z. B. NoSQL, Konfigurationswerkzeuge, Service Discovery) kennen. + +[[LZ-4-4]] ==== LZ 4-4: Resilience Patterns benennen -* Messaging Patterns: Request/Reply, Publish/Subscribe und deren Resilience-Eigenschaften. +* (OPTIONAL) Messaging Patterns: Request/Reply, Publish/Subscribe und deren Resilience-Eigenschaften. * Resilience-Strategien für dezentrale Datenhaltung und redundante Architektur. -* Nutzung von Mechanismen wie Circuit Breaker, Graceful Degradation und Bulkhead zur Sicherstellung der Verfügbarkeit. +* Unterschiede zwischen High-Availability und Resilience verstehen und Praxisbeispiele nennen +* (OPTIONAL) Nutzung von Mechanismen wie Circuit Breaker, Bulkhead und Graceful Degradation zur Sicherstellung der Verfügbarkeit in Szenarien, wo Systemteile unterschiedliche Verfügbarkeitsanforderungen haben. [[LZ-4-5]] ==== LZ 4-5: Sicherheitsauswirkungen von Integrationsmethoden kennen und berücksichtigen -* Vergleich von Authentifizierungs- und Autorisierungsmechanismen (z. B. OAuth, Kerberos). +* (OPTIONAL) Vergleich von Authentifizierungs- und Autorisierungsmechanismen (z. B. OAuth, Kerberos). * Auswirkungen von synchroner (z. B. RPC) vs. asynchroner Integration (z. B. Messaging) auf Sicherheit und Datenintegrität. * Implementierung sicherer Schnittstellen und Makroarchitektur für verteilte Systeme. @@ -51,38 +54,52 @@ // tag::EN[] [[LG-4-1]] -==== LG 4-1: Compare Integration Strategies (using DDD Strategic Design as an example) +==== LG 4-1: Compare Integration Strategies (Using the Example of DDD Strategic Design) -* Understand Strategic Design from Domain-Driven Design (DDD) for integration (e.g., Anti-Corruption Layer, Shared Kernel, Bounded Context). -* Evaluate the pros and cons of integration approaches like REST, Messaging, or Database Integration based on specific quality goals. -* Utilize Frontend Integration and Middleware for legacy systems. -Practical application: Integrate old data models through transformation and mapping. +* Understand and explain Strategic Design from Domain-Driven Design (DDD) and its relationship patterns (e.g., Anti-Corruption Layer, Shared Kernel, Customer/Supplier). +* Represent and describe the module boundaries of a system using "Bounded Context" and perform AS-IS/TO-BE comparisons. +* Justify which patterns from Strategic Design can or cannot be used for an integration/interface based on quality goals. [[LG-4-2]] -==== LG 4-2: Explain and Select Consistency Models (CAP Theorem) +==== LG 4-2: Select and Justify Technical Integration Mechanisms -* Explain the CAP Theorem: Trade-offs between Consistency, Availability, and Partition Tolerance. -* Compare ACID and BASE models: Use cases in distributed systems. -* Practical example: Choosing an appropriate consistency model based on system requirements like latency and scalability. +* Evaluate the advantages and disadvantages of technical integration mechanisms such as frontend integration, middle-tier integration (REST, RPC, Messaging), or database integration based on specific quality goals of the system and the required experience/skills of the development teams. +* (Optional) Compare frontend integration (e.g., links, client-side includes, microfrontends) and middleware for legacy systems and their impacts. +* (Optional) Practical application in brownfield scenarios: integration of legacy data models through transformation and mapping. [[LG-4-3]] -==== LG 4-3: Identify Resilience Patterns -* Messaging Patterns: Request/Reply, Publish/Subscribe, and their resilience properties. -* Resilience Strategies for decentralized data storage and redundant architectures. -* Use mechanisms like Circuit Breaker, Graceful Degradation, and Bulkhead to ensure availability. +==== LG 4-3: Explain and Select Consistency Models (CAP Theorem) + +* Explain the CAP theorem: trade-offs between consistency, availability, and partition tolerance. +* Understand the necessity of partition tolerance. +* Compare ACID and BASE models: guarantees, compromises, and trade-offs, as well as their resulting applicability in distributed systems. +* Explain the difference between "consistency" in ACID and BASE using practical examples. +* (Optional) Provide practical examples of ACID and BASE transactions in distributed systems. +* Justify CP vs. AP system design based on quality goals. +* (Optional) Practical example: choosing a suitable consistency model based on system requirements such as latency and scalability. +* (Optional) Know product examples from different categories (e.g., NoSQL, configuration tools, service discovery). [[LG-4-4]] -==== LG 4-4: Understand and Consider Security Impacts of Integration Methods +==== LG 4-4: Identify and select Resilience Patterns -* Compare Authentication and Authorization mechanisms (e.g., OAuth, Kerberos). -* Explore the security and data integrity implications of synchronous (e.g., RPC) vs. asynchronous integration (e.g., Messaging). -* Implement secure interfaces and macro-architectures for distributed systems. +* (Optional) Messaging Patterns: Request/Reply, Publish/Subscribe, and their resilience properties. +* Resilience strategies for decentralized data storage and redundant architecture. +* Understand the differences between high availability and resilience and provide practical examples. +* (Optional) Use mechanisms like Circuit Breaker, Bulkhead, and Graceful Degradation to ensure availability in scenarios where system components have different availability requirements. +* Understand the impact of resilience patterns on well-known operations metrics like MTTR and MTBF and their interdependency with fast delivery of bugfixes/releases. [[LG-4-5]] -==== LG 4-5: (OPTIONAL) Understand and Design Event-Driven Architectures +==== LG 4-5: Understand and Consider Security Implications of Integration Methods + +* (Optional) Compare authentication and authorization mechanisms (e.g., OAuth, Kerberos). +* Analyze the impact of synchronous (e.g., RPC) vs. asynchronous integration (e.g., Messaging) on security and data integrity. +* Implement secure interfaces and macroarchitecture for distributed systems. + +[[LG-4-6]] +==== LG 4-6: (Optional) Understand and Design Event-Driven Architectures (EDA) -* Introduction to Event-Driven Architectures (EDA): Publishing Domain Events to decouple systems. -* Design an EDA using messaging systems like RabbitMQ or Kafka. -* Address challenges and solutions for Backpressure and decentralized data storage. +* Introduction to Event-Driven Architectures (EDA): publishing domain events to decouple systems. +* Design an EDA with messaging systems like RabbitMQ or Kafka. +* Address challenges and solutions for backpressure and decentralized data storage. // end::EN[] diff --git a/html-theme b/html-theme index 7533fc8..80e28b2 160000 --- a/html-theme +++ b/html-theme @@ -1 +1 @@ -Subproject commit 7533fc8b4c357d15ccd791ecdf0f8fa56af33fd0 +Subproject commit 80e28b237838ff1254edf4b8e8d94ff399ef7ad2 diff --git a/pdf-theme b/pdf-theme index 50badc7..02f5d8b 160000 --- a/pdf-theme +++ b/pdf-theme @@ -1 +1 @@ -Subproject commit 50badc7dc2dd3760eb66821916e7ee76ba421567 +Subproject commit 02f5d8b900633cbea973dd79b114bd1bf6874718 From e230035124c6a2d8020652d18eabef6cb7f880de Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sun, 1 Dec 2024 00:16:06 +0100 Subject: [PATCH 14/20] fixed formatting issue --- docs/06-operations/02-learning-goals.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/06-operations/02-learning-goals.adoc b/docs/06-operations/02-learning-goals.adoc index 187fbd4..303a1df 100644 --- a/docs/06-operations/02-learning-goals.adoc +++ b/docs/06-operations/02-learning-goals.adoc @@ -2,7 +2,7 @@ // tag::DE[] [[LZ-6-1]] -=== LZ 6-1: Unterschiedliche Betriebsmodelle und ihre Auswirkungen erklären und auswählen +==== LZ 6-1: Unterschiedliche Betriebsmodelle und ihre Auswirkungen erklären und auswählen * Operations Team vs. You Build It, You Run It: ** Vergleich zentralisierter Betriebsmodelle (dediziertes Operations-Team) mit dezentralisierten Ansätzen wie DevOps und "You Build It, You Run It". From 40c1bf34c59a1d43ce6f7cf987a05d7f71c393f3 Mon Sep 17 00:00:00 2001 From: Falk Sippach Date: Sun, 1 Dec 2024 00:27:27 +0100 Subject: [PATCH 15/20] #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 6fe731b9d98175b19979b5325593142522b5c3be Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sun, 1 Dec 2024 01:04:29 +0100 Subject: [PATCH 16/20] Moved organisation LG to chapter3 and added references --- docs/01-motivation/02-learning-goals.adoc | 40 +++-------- docs/02-modularization/02-learning-goals.adoc | 31 +++----- docs/02-modularization/references.adoc | 2 +- .../02-learning-goals.adoc | 72 ++++++++++++++++--- docs/03-modules-organization/references.adoc | 2 + docs/05-rollout/02-learning-goals.adoc | 65 +++++++---------- docs/99-references/00-references.adoc | 14 ++-- 7 files changed, 119 insertions(+), 107 deletions(-) diff --git a/docs/01-motivation/02-learning-goals.adoc b/docs/01-motivation/02-learning-goals.adoc index e7f1566..2a259a8 100644 --- a/docs/01-motivation/02-learning-goals.adoc +++ b/docs/01-motivation/02-learning-goals.adoc @@ -23,17 +23,7 @@ - Die Vorteile verschiedener Isolationsarten (Devtime, Runtime, Deployment, Team) bewerten [[LZ-1-3]] -==== LZ 1-3: Wechselwirkung von Architekturtypen und Organisation analysieren und benennen - -- Erklären, wie Beziehungen zwischen Teams und Organisationseinheiten die Architektur von Systemen und damit Aspekte wie Abstimmungsaufwände und Time-to-Market beeinflussen -- Erkennen, wie Conway's Law die Entwicklungsgeschwindigkeit beeinflusst -- Den Zusammenhang zwischen Teamgrenzen und Systemgrenzen analysieren und erklären -- Die Balance zwischen technischer und organisatorischer Struktur erklären -- Unterschiede von Buildtime- und Runtime-Abhängigkeiten für Softwareentwicklungsprozesse erklären -- Die Parallelisierbarkeit von Softwareentwicklungsaufgaben als Architekturziel verstehen - -[[LZ-1-4]] -==== LZ 1-4: Kompromisse der vorgestellten Architekturtypen vermitteln und adaptieren +==== LZ 1-3: Kompromisse der vorgestellten Architekturtypen vermitteln und adaptieren - Die Vor- und Nachteile verschiedener Architekturstile abwägen - Wissen, wie man Architekturentscheidungen dem Business-Kontext anpasst @@ -43,8 +33,8 @@ - Die Kosten von Verteilung und Service-Kommunikation realistisch einschätzen -[[LZ-1-5]] -==== LZ 1-5: Langfristige Qualitätsziele von flexiblen Architekturen benennen +[[LZ-1-4]] +==== LZ 1-4: Langfristige Qualitätsziele von flexiblen Architekturen benennen - Zentrale Qualitätsmerkmale flexibler Architekturen kennen - Verstehen, warum Flexibilität und schnelles Feedback strategische Ziele sind @@ -54,8 +44,8 @@ - Die Rolle von Reproduzierbarkeit und Vorhersagbarkeit verstehen - Automatisierbarkeit als Qualitätsziel erkennen -[[LZ-1-6]] -==== LZ 1-6: Typische Architekturentscheidungen von flexiblen Architekturen erklären und begründen +[[LZ-1-5]] +==== LZ 1-5: Typische Architekturentscheidungen von flexiblen Architekturen erklären und begründen - Architekturentscheidungen durch Businessziele und Qualitätsszenarien begründen - Die Notwendigkeit bestimmter Architekturmuster erklären @@ -97,17 +87,7 @@ - Evaluate benefits of different isolation types (devtime, runtime, deployment, team) [[LG-1-3]] -==== LG 1-3: Analyze and Define the Interplay Between Architecture Types and Organization - -- Explain how relationships between teams and organizational units influence system architecture, affecting coordination overhead and time-to-market -- Recognize how Conway's Law impacts development speed -- Analyze and explain the correlation between team boundaries and system boundaries -- Explain the balance between technical and organizational structure -- Explain differences between buildtime and runtime dependencies in software development processes -- Understand parallel software development capability as an architectural goal - -[[LG-1-4]] -==== LG 1-4: Communicate and Adapt Trade-offs of Presented Architecture Types +==== LG 1-3: Communicate and Adapt Trade-offs of Presented Architecture Types - Weigh advantages and disadvantages of different architectural styles - Know how to adapt architectural decisions to business context @@ -116,8 +96,8 @@ - Understand when combining different architectural styles makes sense - Realistically assess costs of distribution and service communication -[[LG-1-5]] -==== LG 1-5: Define Long-term Quality Goals of Flexible Architectures +[[LG-1-4]] +==== LG 1-4: Define Long-term Quality Goals of Flexible Architectures - Know core quality characteristics of flexible architectures - Understand why flexibility and rapid feedback are strategic goals @@ -127,8 +107,8 @@ - Understand the role of reproducibility and predictability - Recognize automation capability as a quality goal -[[LG-1-6]] -==== LG 1-6: Explain and justify Typical Architectural Decisions in Flexible Architectures +[[LG-1-5]] +==== LG 1-5: Explain and justify Typical Architectural Decisions in Flexible Architectures - Justify architectural decisions through business goals and quality scenarios - Explain the necessity of specific architectural patterns diff --git a/docs/02-modularization/02-learning-goals.adoc b/docs/02-modularization/02-learning-goals.adoc index 01c3573..e2d5bc7 100644 --- a/docs/02-modularization/02-learning-goals.adoc +++ b/docs/02-modularization/02-learning-goals.adoc @@ -17,27 +17,21 @@ * Isolationsebenen: Unterschiede zwischen modularer Isolation im Code, in der Laufzeitumgebung und bei Netzwerkschnittstellen. [[LZ-2-3]] -==== 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. - -[[LZ-2-4]] -==== LZ 2-4: Modularisierungskonzepte bewerten und auswählen +==== 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ätsziele: Auswahl einer Modularisierung passend zu Anforderungen wie Parallelisierung der Entwicklung oder unabhängiges Deployment. -[[LZ-2-5]] -==== LZ 2-5: Modularisierungsstrategien bewerten +[[LZ-2-4]] +==== 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-6]] -==== LZ 2-6: Aufwand und Nutzen von Modularisierungsstrategien gegenüberstellen +[[LZ-2-5]] +==== 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 und verbesserte Verständlichkeit. @@ -60,24 +54,19 @@ * Levels of isolation: Differentiating modular isolation in code, runtime environments, and network interfaces. [[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. - -[[LG-2-4]] -==== LG 2-4: Evaluating and selecting modularization concepts +==== 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. * Quality goals: Choosing modularization approaches suitable for requirements like development parallelization or independent deployment. -[[LG-2-5]] -==== LG 2-5: Assessing modularization strategies +[[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. -[[LG-2-6]] -==== LG 2-6: Contrasting the costs and benefits of modularization strategies +[[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, and improved system comprehensibility. * Module boundaries and complexity: Analyzing how module boundary choices affect complexity and development effort. diff --git a/docs/02-modularization/references.adoc b/docs/02-modularization/references.adoc index 170973e..c49d6b7 100644 --- a/docs/02-modularization/references.adoc +++ b/docs/02-modularization/references.adoc @@ -1,5 +1,5 @@ === {references} -<>, <>, <>, <>, <>, <> +<>, <>, <>, <>, <> diff --git a/docs/03-modules-organization/02-learning-goals.adoc b/docs/03-modules-organization/02-learning-goals.adoc index 5ecc1c6..3d18e06 100644 --- a/docs/03-modules-organization/02-learning-goals.adoc +++ b/docs/03-modules-organization/02-learning-goals.adoc @@ -3,32 +3,82 @@ // tag::DE[] [[LZ-3-1]] -==== LZ 3-1: Conway's Law anhand von Beispielen erklären +==== LZ 3-1: Wechselwirkung von Architekturtypen und Organisation analysieren und benennen -Die Teilnehmenden sollen das Prinzip von Conway's Law verstehen und anhand praktischer Beispiele verdeutlichen können, wie die Kommunikationsstrukturen einer Organisation die Softwarearchitektur prägen. Ziel ist es, die Auswirkungen dieser Wechselwirkungen bewusst zu machen und für Architekturentscheidungen zu nutzen. +- Erklären, wie Beziehungen zwischen Teams bzw. Organisationseinheiten die Architektur von Systemen beeinflussen und damit Auswirkungen auf Abstimmungsaufwände und Time-to-Market haben +- Erkennen, wie Conway's Law die Entwicklungsgeschwindigkeit und Änderungsfähigkeit von Systemen beeinflusst +- Den Zusammenhang zwischen Teamgrenzen und Systemgrenzen analysieren und erklären +- (OPTIONAL) Die Balance zwischen technischer und organisatorischer Struktur erklären +- Unterschiede von Buildtime- und Runtime-Abhängigkeiten für Softwareentwicklungsprozesse erklären +- Die Parallelisierbarkeit von Softwareentwicklungsaufgaben als Architekturziel verstehen +- (OPTIONAL) Darstellen wie organisatorische Änderungen die Software beeinflussen und umgekehrt, um bewusste Entscheidungen für Organisations- und Softwarearchitektur treffen zu können. [[LZ-3-2]] -==== LZ 3-2: Context Maps für Stakeholder Management nutzen - -Die Teilnehmenden lernen, Domain-Driven Design (DDD) Context Maps einzusetzen, um den aktuellen Zustand (AS-IS) und einen gewünschten zukünftigen Zustand (TO-BE) einer Systemlandschaft darzustellen. Dabei wird auch das Einbinden von Stakeholdern in den Veränderungsprozess thematisiert. Ziel ist es, Context Maps als Kommunikations- und Planungswerkzeug zu verstehen und anzuwenden. +==== LZ 3-2: Kommunikationsstruktur der Organisation bei Zerlegung berücksichtigen +* Conway’s Law: Bedeutung verstehen 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. [[LZ-3-3]] -==== LZ 3-3: Wechselwirkungen zwischen Organisation und Software Systemen erklären und analysieren +==== LZ 3-3: Context Maps für Stakeholder Management nutzen -Die Teilnehmenden sollen die bidirektionalen Einflüsse zwischen Organisationsstrukturen und Softwarearchitekturen verstehen und analysieren können. Dabei wird der Fokus darauf gelegt, wie organisatorische Änderungen Software beeinflussen und umgekehrt, um eine bessere Abstimmung zwischen beiden Welten zu erreichen. +* Context Maps aus Domain-Driven Design (DDD) einsetzen, um den aktuellen IST-Zustand und einen gewünschten zukünftigen SOLL-Zustand einer Systemlandschaft darzustellen. +* (OPTIONAL) Context Maps zielgruppenabhängig (Entwickler vs. Management) als Kommunikations- und Planungswerkzeug verstehen und anwenden. [[LZ-3-4]] -==== LZ 3-4: Begriffe wie Teamorganisation und sozio-technische Architekturen einordnen +==== LZ 3-4: (OPTIONAL) Begriffe wie Teamorganisation und sozio-technische Architekturen sicher verwenden + +* Begriffe wie Team-Organisation, sozio-technische Architekturen und ähnliche Konzepte einordnen. +* Bedeutung im Kontext moderner Softwareentwicklung erklären. +* Verständnis für die Verknüpfung technischer und sozialer Aspekte bei der Architekturgestaltung zu entwickeln. + +[[LZ-3-5]] +==== LZ 3-5: Außerhalb des eigenen Einflussbereiches getroffene Makroarchitekturentscheidungen identifizieren -Die Teilnehmenden sollen Begriffe wie Team-Organisation, sozio-technische Architekturen und ähnliche Konzepte einordnen und deren Bedeutung im Kontext moderner Softwareentwicklung erklären können. Ziel ist es, ein Verständnis für die Verknüpfung technischer und sozialer Aspekte bei der Architekturgestaltung zu entwickeln. +- Unterschied zwischen Mikro- und Makroarchitektur verstehen, um potenzielle Einschränkungen und Abstimmungsaufwände zu identifizieren und proaktiv zu adressieren. +- Die Abgrenzung zwischen Makro- und Mikroarchitektur verstehen, um potenzielle Einschränkungen und Möglichkeiten bei Deployment-Strategien zu identifizieren. +- Makroarchitekturentscheidungen wie Kommunikationsprotokolle, Betriebsstandards und Plattformvorgaben analysieren und deren Auswirkungen auf Deployment- und Runtime-Methoden bewerten. +- Die Bedeutung von zentralen Plattformstandards für die Effizienz von Kommunikation und Deployments/Softwarelieferungen erkennen. // end::DE[] // tag::EN[] [[LG-3-1]] -==== LG 3-1: Explain Conway's Law using examples +==== LG 3-1: Analyze and name the interaction between architecture types and organization -// end::EN[] +* 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 + +[[LG-3-2]] +==== LG 3-2: Consider the organization's communication structure when decomposing + +* 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. +[[LG-3-3]] +==== LG 3-3: Use context maps for stakeholder management +* 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). + +[[LG-3-4]] +==== LG 3-4: (OPTIONAL) Use terms like team organization and socio-technical architectures confidently + +* 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. + +[[LG-3-5]] +==== LG 3-5: Identify macro-architecture decisions made outside your sphere of influence + +* 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-modules-organization/references.adoc b/docs/03-modules-organization/references.adoc index da9242d..128f8ee 100644 --- a/docs/03-modules-organization/references.adoc +++ b/docs/03-modules-organization/references.adoc @@ -1 +1,3 @@ === {references} + +<>, <>, <>, <>, <> \ No newline at end of file diff --git a/docs/05-rollout/02-learning-goals.adoc b/docs/05-rollout/02-learning-goals.adoc index d985281..b03e0db 100644 --- a/docs/05-rollout/02-learning-goals.adoc +++ b/docs/05-rollout/02-learning-goals.adoc @@ -2,55 +2,48 @@ // tag::DE[] [[LZ-5-1]] -==== LZ 5-1: Außerhalb des eigenen Einflussbereiches getroffene Makroarchitekturentscheidungen identifizieren - -- Makroarchitekturentscheidungen wie Kommunikationsprotokolle, Betriebsstandards und Plattformvorgaben analysieren und deren Auswirkungen auf Deployment- und Runtime-Methoden bewerten. -- Die Abgrenzung zwischen Makro- und Mikroarchitektur verstehen, um potenzielle Einschränkungen und Möglichkeiten bei Deployment-Strategien zu identifizieren. -- Die Bedeutung von zentralen Plattformstandards für die Vereinheitlichung und Effizienz von Deployments erkennen. - -[[LZ-5-2]] -==== LZ 5-2: Voraussetzungen und Auswirkungen für Continuous Deployment benennen +==== LZ 5-1: Voraussetzungen und Auswirkungen für Continuous Deployment benennen - Anforderungen an eine CI/CD-Pipeline erklären, einschließlich Automatisierungsgrad, Tests und Infrastrukturintegration. - Die Rolle von DevOps in Continuous Deployment verstehen und organisatorische Implikationen erkennen. - Unterschiede zwischen traditionellen und modernen Deployment-Ansätzen, wie Immutable Infrastructure oder Infrastructure as Code, evaluieren. - Risiken und Vorteile von Continuous Deployment, einschließlich Zero Downtime, im Kontext verschiedener Projekte abwägen. -[[LZ-5-3]] -==== LZ 5-3: (OPTIONAL) Unterschiede von IaaS, PaaS, CaaS, FaaS erklären und auswählen +[[LZ-5-2]] +==== LZ 5-2: (OPTIONAL) Unterschiede von IaaS, PaaS, CaaS, FaaS erklären und auswählen - Die technischen Eigenschaften und Anwendungsbereiche der verschiedenen Plattformansätze (IaaS, PaaS, CaaS, FaaS) erläutern. - Kriterien für die Auswahl des passenden Plattformansatzes in Abhängigkeit von Projektanforderungen wie Skalierbarkeit, Flexibilität und Kosten aufstellen. - Auswirkungen der Plattformwahl auf die Deployment-Strategie analysieren und Entscheidungen zu Containerisierung (z. B. Docker, Kubernetes) oder serverlosen Ansätzen treffen. -[[LZ-5-4]] -==== LZ 5-4: Zero Downtime Methodiken und ihre Auswirkungen benennen und auswählen +[[LZ-5-3]] +==== LZ 5-3: Zero Downtime Methodiken und ihre Auswirkungen benennen und auswählen - Verschiedene Zero-Downtime-Strategien (Blue-Green-Deployment, Canary Releases, Rolling Updates) erläutern und deren Vor- und Nachteile analysieren. - Die Rolle von Immutable Infrastructure und Automatisierung für Zero Downtime erklären. - Herausforderungen und Architekturanforderungen für Zero-Downtime-Deployments evaluieren. -[[LZ-5-5]] -==== LZ 5-5: Unterschiede zwischen Continuous Integration, Continuous Deployment und Continuous Delivery erklären +[[LZ-5-4]] +==== LZ 5-4: Unterschiede zwischen Continuous Integration, Continuous Deployment und Continuous Delivery erklären - Die Bedeutung von Continuous Integration (CI) als Grundlage für Continuous Deployment und Delivery erläutern. - Unterschiede in Zielsetzung und Automatisierungsgrad zwischen den drei Konzepten analysieren. - Abhängigkeiten von Architekturentscheidungen auf den Einsatz von CI/CD-Pipelines beschreiben. -[[LZ-5-6]] -==== LZ 5-6: (OPTIONAL) Deployment-spezifische Sicherheitsanforderungen benennen +[[LZ-5-5]] +==== LZ 5-5: (OPTIONAL) Deployment-spezifische Sicherheitsanforderungen benennen - Anforderungen an den Schutz von Secrets (z. B. API-Keys, Zertifikate) und Sicherheitsrichtlinien im Deployment-Prozess erklären. - Konzepte wie Zugriffskontrollen, Verschlüsselung und Compliance-Anforderungen in Deployment-Strategien integrieren. - Werkzeuge zur Verwaltung sicherheitsrelevanter Informationen (Secret Store) einsetzen und bewerten. -[[LZ-5-7]] -==== LZ 5-7: (OPTIONAL) Die Rolle von Observability im Deployment-Prozess erklären +[[LZ-5-6]] +==== LZ 5-6: (OPTIONAL) Die Rolle von Observability im Deployment-Prozess erklären - Anforderungen an ein Monitoring-System und dessen Bedeutung für den Deployment-Erfolg erläutern. - Die Rolle von zentralisierten Logging- und Metriksystemen (z. B. Elastic Stack, Prometheus, Grafana) erklären. - Strategien entwickeln, um potenzielle Probleme im Deployment-Prozess frühzeitig zu erkennen und zu adressieren. -[[LZ-5-8]] -==== LZ 5-8: (OPTIONAL) Kosten- und Ressourceneffizienz im Deployment optimieren +[[LZ-5-7]] +==== LZ 5-7: (OPTIONAL) Kosten- und Ressourceneffizienz im Deployment optimieren - Methoden zur Kostenoptimierung im Deployment evaluieren (z. B. Reserved Instances, Spot Instances, Serverless). - Auswirkungen der Wahl von Cloud- und Virtualisierungsstrategien auf die Betriebskosten und Ressourcennutzung analysieren. - Deployment-Methoden entwickeln, die Skalierbarkeit und Effizienz maximieren. @@ -60,50 +53,44 @@ // tag::EN[] [[LG-5-1]] -==== LG 5-1: Identify Macro-architectural Decisions Beyond Your Sphere of Influence -- Analyze macro-architectural decisions such as communication protocols, operational standards, and platform requirements, evaluating their impact on deployment and runtime methods -- Understand the distinction between macro and micro architecture to identify potential constraints and opportunities in deployment strategies -- Recognize the importance of central platform standards for deployment uniformity and efficiency - -[[LG-5-2]] -==== LG 5-2: Specify prerequisites and implications for Continuous Deployment +==== LG 5-1: Specify prerequisites and implications for Continuous Deployment - Utilize quality goals to explain CI/CD pipeline requirements, including automation levels, testing, and infrastructure integration - Understand DevOps' role in Continuous Deployment and recognize organizational implications - Evaluate differences between traditional and modern deployment approaches, such as Immutable Infrastructure or Infrastructure as Code - Assess risks and benefits of Continuous Deployment, including zero downtime, in various project contexts -[[LG-5-3]] -==== LG 5-3: (OPTIONAL) Explain and select differences between IaaS, PaaS, CaaS, and FaaS +[[LG-5-2]] +==== LG 5-2: (OPTIONAL) Explain and select differences between IaaS, PaaS, CaaS, and FaaS - Describe technical characteristics and application areas of different platform approaches (IaaS, PaaS, CaaS, FaaS) - Establish criteria for selecting appropriate platform approaches based on project requirements like scalability, flexibility, and costs - Analyze platform choice impacts on deployment strategy and make decisions regarding containerization (e.g., Docker, Kubernetes) or serverless approaches -[[LG-5-4]] -==== LG 5-4: Identify and select Zero Downtime methodologies and their implications +[[LG-5-3]] +==== LG 5-3: Identify and select Zero Downtime methodologies and their implications - Explain various zero-downtime strategies (Blue-Green Deployment, Canary Releases, Rolling Updates) and analyze their pros and cons - Explain the role of Immutable Infrastructure and automation for zero downtime - Evaluate challenges and architectural requirements for zero-downtime deployments -[[LG-5-5]] -==== LG 5-5: Explain differences between Continuous Integration, Continuous Deployment, and Continuous Delivery +[[LG-5-4]] +==== LG 5-4: Explain differences between Continuous Integration, Continuous Deployment, and Continuous Delivery - Explain the significance of Continuous Integration (CI) as a foundation for Continuous Deployment and Delivery - Analyze differences in objectives and automation levels between the three concepts - Describe how architectural decisions influence CI/CD pipeline implementation -[[LG-5-6]] -==== LG 5-6: (OPTIONAL) Specify deployment-specific security requirements +[[LG-5-5]] +==== LG 5-5: (OPTIONAL) Specify deployment-specific security requirements - Explain requirements for protecting secrets (e.g., API keys, certificates) and security policies in the deployment process - Integrate concepts like access controls, encryption, and compliance requirements into deployment strategies - Implement and evaluate tools for managing security-relevant information -[[LG-5-7]] -==== LG 5-7: (OPTIONAL) Explain the role of observability in the Deployment Process +[[LG-5-6]] +==== LG 5-6: (OPTIONAL) Explain the role of observability in the Deployment Process - Explain monitoring system requirements and their importance for deployment success - Explain the role of centralized logging and metrics systems (e.g., Elastic Stack, Prometheus, Grafana) - Develop strategies to identify and address potential problems in the deployment process early -[[LG-5-8]] -==== LG 5-8: (OPTIONAL) Shop options to optimize cost and resource efficiency in the deployment process +[[LG-5-7]] +==== LG 5-7: (OPTIONAL) Shop options to optimize cost and resource efficiency in the deployment process - Evaluate methods for cost optimization in deployment and runtime (e.g., Reserved Instances, Spot Instances, Serverless) - Analyze how cloud and virtualization strategy choices impact operational costs and resource utilization - Develop deployment methods that maximize scalability and efficiency diff --git a/docs/99-references/00-references.adoc b/docs/99-references/00-references.adoc index 68c52b3..97cea8f 100644 --- a/docs/99-references/00-references.adoc +++ b/docs/99-references/00-references.adoc @@ -14,6 +14,10 @@ This section contains references that are cited in the curriculum. - [[[brewer,Brewer 2000]]] Eric Brewer, Towards Robust Distributed Systems, PODC Keynote, July-19-2000 +**C** + +- [[conway, Conway 1968]] Melvin E. Conway, How Do Committees Invent?, Datamation, 1968, https://en.wikipedia.org/wiki/Conway's_law + **E** - [[[evansddd,Eric Evans 2003]]] Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison- Wesley Professional, 2003 @@ -46,21 +50,21 @@ This section contains references that are cited in the curriculum. in Decomposing Systems into Modules. Communications of the ACM 15(12):1053--1058, 1972. +**S** + +- [[[sommerville, 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 **T** - [[[takada,Takada 2013]]] Mikito Takada, Distributed Systems for Fun and Profit, http://book.mixu.net/distsys/ (Guter Einstieg und Überblick) - [[[tanenbaum,Tanenbaum, van Steen 2006]]] Andrew Tanenbaum, Marten van Steen, Distributed Systems – Principles and Paradigms, Prentice Hall, 2nd Edition, 2006 +- [[[skeltonpais,Skelton, Pais 2019]]] Mathew Skelton, Manuel Pais - TEAM TOPOLOGIES: ORGANIZING BUSINESS AND TECHNOLOGY TEAMS FOR FAST FLOW, IT Revolution, 2019, ISBN 978-1-942788-81-2 **V** -- [[[vossencloud,Vossen, Haselmann, Hoeren 2012]]] Gottfried Vossen, Till Haselmann, Thomas Hoeren: Cloud-Computing für Unternehmen: Technische, wirtschaftliche, rechtliche und organisatorische Aspekte, dpunkt, 2012, ISBN 978-3- 89864-808-0 +- [[[vossencloud,Vossen, Haselmann, Hoeren 2012]]] Gottfried Vossen, Till Haselmann, Thomas Hoeren: Cloud-Computing für Unternehmen: Technische, wirtschaftliche, rechtliche und organisatorische Aspekte, dpunkt, 2012, ISBN 978-3-89864-808-0 **W** - [[[wolffcd,Wolff 2016]]] Eberhard Wolff: Continuous Delivery: Der pragmatische Einstieg, 2. Auflage, dpunkt, 2016, ISBN 978-3-86490-371-7 - [[[wolffms,Wolff 2018]]] Eberhard Wolff: Microservices - Grundlagen flexibler Software Architekturen, 2. Auflage, dpunkt, 2018, ISBN 978-3-86490-555-1 - [[[wolfpaas, Wolff, Müller, Löwenstein 2013]]] Eberhard Wolff, Stephan Müller, Bernhard Löwenstein: PaaS - Die wichtigsten Java Clouds auf einen Blick, entwickler.press, 2013 - -**1** - -- [[[twelvefactor,12 Factor App 2012]]] 12 Factor App, Guidelines for building apps on Heroku http://12factor.net/ From 0b0b7d3eefc9d89efceb4e15b42f4d5f71620cf3 Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sun, 1 Dec 2024 01:21:53 +0100 Subject: [PATCH 17/20] fixed references --- docs/01-motivation/references.adoc | 2 +- docs/03-modules-organization/references.adoc | 2 +- docs/04-integration/references.adoc | 2 +- docs/99-references/00-references.adoc | 6 ++---- 4 files changed, 5 insertions(+), 7 deletions(-) diff --git a/docs/01-motivation/references.adoc b/docs/01-motivation/references.adoc index cfd0993..193c7cc 100644 --- a/docs/01-motivation/references.adoc +++ b/docs/01-motivation/references.adoc @@ -1,6 +1,6 @@ === {references} -<>, <>, <> +<>, <>, <>, <> diff --git a/docs/03-modules-organization/references.adoc b/docs/03-modules-organization/references.adoc index 128f8ee..6b77de4 100644 --- a/docs/03-modules-organization/references.adoc +++ b/docs/03-modules-organization/references.adoc @@ -1,3 +1,3 @@ === {references} -<>, <>, <>, <>, <> \ No newline at end of file +<>, <>, <>, <>, <> \ No newline at end of file diff --git a/docs/04-integration/references.adoc b/docs/04-integration/references.adoc index 925216b..9e00087 100644 --- a/docs/04-integration/references.adoc +++ b/docs/04-integration/references.adoc @@ -1,6 +1,6 @@ === {references} -<>, <>, <> +<>, <>, <>, <>, <>, <>, <>, <>, <>, <> diff --git a/docs/99-references/00-references.adoc b/docs/99-references/00-references.adoc index 97cea8f..8da1758 100644 --- a/docs/99-references/00-references.adoc +++ b/docs/99-references/00-references.adoc @@ -12,11 +12,12 @@ This section contains references that are cited in the curriculum. **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 - [[[brewer,Brewer 2000]]] Eric Brewer, Towards Robust Distributed Systems, PODC Keynote, July-19-2000 **C** -- [[conway, Conway 1968]] Melvin E. Conway, How Do Committees Invent?, Datamation, 1968, https://en.wikipedia.org/wiki/Conway's_law +- [[[conway,Conway 1968]]] Melvin E. Conway, How Do Committees Invent?, Datamation, 1968, https://en.wikipedia.org/wiki/Conway%27s_law **E** @@ -50,9 +51,6 @@ This section contains references that are cited in the curriculum. in Decomposing Systems into Modules. Communications of the ACM 15(12):1053--1058, 1972. -**S** - -- [[[sommerville, 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 **T** - [[[takada,Takada 2013]]] Mikito Takada, Distributed Systems for Fun and Profit, http://book.mixu.net/distsys/ (Guter Einstieg und Überblick) From 809b484b74e8858001dddac0b13eb27d6f92fbdd Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sun, 1 Dec 2024 01:29:13 +0100 Subject: [PATCH 18/20] 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 19/20] 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 20/20] 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]]