From 18692ac7618d5b62f255f998b33a1a44035e8f5e Mon Sep 17 00:00:00 2001 From: Falk Sippach Date: Fri, 29 Nov 2024 18:37:02 +0100 Subject: [PATCH 01/12] #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 02/12] 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 03/12] 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 04/12] 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 05/12] 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 06/12] 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 07/12] 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 08/12] 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 09/12] 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 10/12] 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 11/12] 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 12/12] 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