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..885552f --- /dev/null +++ b/docs/04-integration/02-learning-goals.adoc @@ -0,0 +1,105 @@ +=== {learning-goals} + +// tag::DE[] +[[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. + +[[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. + +[[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. +* (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 + +* (OPTIONAL) Messaging Patterns: Request/Reply, Publish/Subscribe und deren Resilience-Eigenschaften. +* Resilience-Strategien für dezentrale Datenhaltung und redundante Architektur. +* 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 + +* (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. + +[[LZ-4-6]] +==== 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. +* Herausforderungen und Lösungen bei Backpressure und dezentraler Datenhaltung. + +// end::DE[] + +// tag::EN[] + +[[LG-4-1]] +==== LG 4-1: Compare Integration Strategies (Using the Example of DDD Strategic Design) + +* 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: Select and Justify Technical Integration Mechanisms + +* 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: 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: Identify and select Resilience Patterns + +* (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: 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 with 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 60ab6f9..cacb3b5 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::05-rollout/00-structure.adoc[{include_configuration}]