Merge pull request #54 from isaqb-org/TimRiemer-master

fix format and typo

docs/00b-basics/02-curriculum-structure-and-chronological-breakdown.adoc

@@ -1,7 +1,7 @@
 // tag::DE[]
 === Struktur des Lehrplans und empfohlene zeitliche Aufteilung
 
-[cols="<,>", options="header"]
+[cols="<,>,>", options="header"]
 |===
 | Inhalt 
 | Empfohlene Mindestdauer (min) 

docs/00b-basics/04-prerequisites-for-this-training.adoc

@@ -3,19 +3,20 @@
 
 Teilnehmerinnen und Teilnehmer **sollten** folgende Kenntnisse und/oder Erfahrung mitbringen:
 
-- Grundlagen der Beschreibung von Architekturen mit Hilfe verschiedener Sichten, übergreifender Konzepte, Entwurfsentscheidungen, Randbedingungen etc., wie es im CPSA- F (Foundation Level) vermittelt wird.
+- Grundlagen der Beschreibung von Architekturen mithilfe verschiedener Sichten, übergreifender Konzepte, Entwurfsentscheidungen, Randbedingungen etc., wie es im CPSA-F (Foundation Level) vermittelt wird.
 - Erfahrung mit der Implementierung und Architektur in agilen Projekten.
 - Erfahrungen aus der Entwicklung und Architektur klassischer Systeme mit den typischen
 Herausforderungen.
 
 **Hilfreich** für das Verständnis einiger Konzepte sind darüber hinaus:
 
 - Verteilte Systeme
-  * Probleme und Herausforderungen bei der Implementerung verteilter Systeme o Typische verteilte Algorithmen
+  * Probleme und Herausforderungen bei der Implementierung verteilter Systeme
+  * Typische verteilte Algorithmen
   * Internet-Protokolle
 - Kenntnisse über Modularisierungen
   * Fachliche Modularisierung
-  * Technische Umsetzungen wie Pakete oder Bibiliotheken
+  * Technische Umsetzungen wie Pakete oder Bibliotheken
 - Klassische Betriebs- und Deployment-Prozesse
 // end::DE[]
 

docs/00b-basics/05-curriculum-outline.adoc

@@ -3,7 +3,7 @@
 
 Die einzelnen Abschnitte des Lehrplans sind gemäß folgender Gliederung beschrieben:
 
-- **Begriffe/Konzepte**: Wesentliche Kernbegriffe dieses Themas.
+- **Begriffe/Konzepte**: wesentliche Kernbegriffe dieses Themas.
 - **Unterrichts-/Übungszeit**: Legt die Unterrichts- und Übungszeit fest, die für dieses Thema bzw. dessen Übung in einer akkreditierten Schulung mindestens aufgewendet werden muss.
 - **Lernziele**: Beschreibt die zu vermittelnden Inhalte inklusive ihrer Kernbegriffe und -konzepte.
 

docs/01-motivation/02-learning-goals.adoc

@@ -18,16 +18,16 @@ dient.
 
 [[LZ-1-2]]
 ==== LZ 1-2: Wechselwirkung von Architektur-Typen und Organisation
-Sie haben die Treiber für die Architektur-Typen verstanden, die in diesem Lehrplanmodul vermittelt werden, welche Konsequenzen die Treiber für die Architekturen haben und wie die Wechselwirkung der Architekturen mit Organisation, Prozessen und Technologien ist.
+Sie haben die Treiber für die Architektur-Typen verstanden, die in diesem Lehrplanmodul vermittelt werden, welche Konsequenzen diese Treiber für die Architekturen haben und wie die Wechselwirkung der Architekturen mit Organisation, Prozessen und Technologien aussehen.
 
 [[LZ-1-3]]
-==== LZ 1-3: Tradeoffs der vorgestellten Architektur-Typen vermitteln und adaptieren
-Sie haben die Tradeoffs der vorgestellten Architektur-Typen (mindestens Microservices, Self Contained Systems und Deployment Monolithen) verstanden und können diese sowohl vermitteln als auch im Rahmen konkreter Projekte/Systementwicklungen anwenden, um angemessene Architekturentscheidungen zu treffen.
+==== LZ 1-3: Kompromisse der vorgestellten Architektur-Typen vermitteln und adaptieren
+Sie haben die Kompromisse der vorgestellten Architektur-Typen (mindestens Microservices, Self Contained Systems und Deployment Monolithen) verstanden und können diese sowohl vermitteln als auch im Rahmen konkreter Projekte/Systementwicklungen anwenden, um angemessene Architekturentscheidungen zu treffen.
 
 [[LZ-1-4]]
 ==== LZ 1-4: Verständnis für Rahmenbedingungen von verteilten Systemen
 
-.Teilnehmer sollen Rahmenbedingungen von verteilten Systemen verstehen, wie folgende:
+.Teilnehmer sollen Rahmenbedingungen von verteilten Systemen verstehen, wie z.B. folgende:
   * Auf die Fähigkeit, neue Features schnell in Produktion bringen zu können, hat die Architektur entscheidenden Einfluss.
   * Abhängigkeiten zwischen Komponenten, die von unterschiedlichen Entwicklungsteams verantwortet werden, beeinflussen die Dauer, bis Software in Produktion gebracht werden kann, weil sie die Kommunikationsaufwände erhöhen und sich Verzögerungen fortpflanzen.
   * Die Automatisierung von Aktivitäten (wie z. B. Test- und Deployment-Prozesse) erhöht die Reproduzierbarkeit, Vorhersagbarkeit und Ergebnisqualität dieser Prozesse. Das kann zu einer Verbesserung des gesamten Entwicklungsprozesses führen.
@@ -36,7 +36,7 @@ Sie haben die Tradeoffs der vorgestellten Architektur-Typen (mindestens Microser
   * Continuous Integration ist eine Voraussetzung für Continuous Delivery.
   * Eine geeignete Architektur ist die Voraussetzung für eine Parallelisierbarkeit der Entwicklung sowie die unabhängige Inbetriebnahme von eigenständigen Bausteinen. Das können, müssen aber nicht „Services“ sein.
   * Einige Änderungsszenarien lassen sich leichter in monolithischen Architekturen umsetzen. Andere Änderungsszenarien lassen sich leichter in verteilten Service-Architekturen umsetzen. Beide Ansätze können kombiniert werden.
-  * Es gibt unterschiedliche Arten der Isolation mit unterschiedlichen Vorteilen. Beispielsweise kann der Ausfall auf eine Komponente begrenzt werden oder änderungen können auf eine Komponente begrenzt werden.
+  * Es gibt unterschiedliche Arten der Isolation mit jeweils unterschiedlichen Vorteilen. Beispielsweise kann der Ausfall auf eine Komponente begrenzt werden oder Änderungen können auf eine Komponente begrenzt werden.
   * Bestimmte Arten der Isolation sind zwischen Prozessen mit Remotekommunikation deutlich einfacher umzusetzen.
   * Remotekommunikation hat aber Nachteile – z. B. viele neue Fehlerquellen.
 

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

@@ -17,7 +17,7 @@
 ** wie ein solcher Baustein deployt wird,
 ** wie ein solcher Baustein getestet wird,
 ** wie ein solcher Baustein skaliert wird.
-* Unterschiedliche Grade an Vorgaben für die Entwicklung eines Bausteins können sinnvoll sein. Einige Vorgaben sollten besser übergeordnet allgemein für die Integration mit anderen Bau- steinen dieser Art gelten. Die übergreifenden Entscheidungen, die alle Systeme beeinflussen, können eine Makro-Architektur bilden - dazu zählen beispielsweise die Kommunikationspro- tokolle oder Betriebsstandards. Mikro-Architektur kann die Architektur eines einzelnen Systems sein. Es ist weitgehend unabhängig von anderen Systemen. Zu große Einschränkungen auf Ebene der Makro-Architektur führen dazu, dass die Architektur insgesamt auf weniger Probleme angewendet werden kann.
+* Unterschiedliche Grade an Vorgaben für die Entwicklung eines Bausteins können sinnvoll sein. Einige Vorgaben sollten besser übergeordnet allgemein für die Integration mit anderen Bausteinen dieser Art gelten. Die übergreifenden Entscheidungen, die alle Systeme beeinflussen, können eine Makro-Architektur bilden - dazu zählen beispielsweise die Kommunikationsprotokolle oder Betriebsstandards. Mikro-Architektur kann die Architektur eines einzelnen Systems sein. Es ist weitgehend unabhängig von anderen Systemen. Zu große Einschränkungen auf Ebene der Makro-Architektur führen dazu, dass die Architektur insgesamt auf weniger Probleme angewendet werden kann.
 
 .Was sollen die Teilnehmer kennen?
 * Die Teilnehmer sollen das Gesetz von Conway kennen.
@@ -40,7 +40,7 @@
 ** Kompilat (Modularisierung mit JARs, Bibliotheken, DLLs etc.)
 ** Laufzeitumgebung (Betriebssystem, virtuelle Maschine oder Container)
 ** Netzwerkprotokoll (Verteilung auf verschiedene Prozesse)
-* Eine Kopplung auf Ebene des Sourcecodes erfordert sehr enge Kooperation sowie gemeinsames SCM. Eine Kopplung auf Ebene des Kompilats bedeutet, dass die Bausteine in der Regel gemeinsam deployt werden müssen. Nur eine Verteilung auf unterschiedliche Anwendun- gen/Prozesse ist praktikabel im Hinblick auf ein unabhängiges Deployment.
+* Eine Kopplung auf Ebene des Sourcecodes erfordert sehr enge Kooperation sowie gemeinsames SCM. Eine Kopplung auf Ebene des Kompilats bedeutet, dass die Bausteine in der Regel gemeinsam deployt werden müssen. Nur eine Verteilung auf unterschiedliche Anwendungen/Prozesse ist praktikabel im Hinblick auf ein unabhängiges Deployment.
 * Teilnehmer verstehen, dass eine vollständige Isolation zwischen Bausteinen nur durch eine Trennung in allen Phasen (Entwicklung, Deployment und Laufzeit) gewährleistet werden kann. Ist das nicht der Fall, können unerwünschte Abhängigkeiten nicht ausgeschlossen wer- den. Gleichzeitig verstehen die Teilnehmer auch, dass es sinnvoll sein kann, aus Gründen wie effizienter Ressourcennutzung oder Komplexitätsreduktion auf eine vollständige Isolation zu verzichten.
 * Teilnehmer verstehen, dass bei der Verteilung auf unterschiedliche Prozesse manche Abhängigkeiten nicht mehr in der Implementierung existieren, sondern erst zur Laufzeit entstehen. Dadurch steigen die Anforderungen an die Überwachung dieser Schnittstellen.
 * Microservices sind unabhängige Deployment-Einheiten und damit auch unabhängige Prozesse, die ihre Funktionen über leichtgewichtige Protokolle exponieren, aber auch ein UI ha- ben können. Für die Implementierung jedes einzelnen Microservices können unterschiedliche Technologieentscheidungen getroffen werden.
@@ -64,9 +64,9 @@
 ** erst zur Laufzeit entsteht,
 ** zur Entwicklungszeit entsteht oder
 ** beim Deployment entsteht.
-* Der Modulschnitt kann entlang fachlicher oder technischer Grenzen erfolgen. In den meisten Fällen empfiehlt sich ein fachlicher Schnitt, da sich so fachliche Anforderungen klarer einem Modul zuordnen lassen und somit nicht mehrere Module für die Umsetzung einer fachlichen Anforderung angepasst werden müssen. Dabei kann jedes Modul sein eigenes Domänenmo- dell im Sinne eines Bounded Context und damit unterschiedliche Sichten auf ein Geschäfts- objekt mit eigenen Daten haben.
+* Der Modulschnitt kann entlang fachlicher oder technischer Grenzen erfolgen. In den meisten Fällen empfiehlt sich ein fachlicher Schnitt, da sich so fachliche Anforderungen klarer einem Modul zuordnen lassen und somit nicht mehrere Module für die Umsetzung einer fachlichen Anforderung angepasst werden müssen. Dabei kann jedes Modul sein eigenes Domänenmodell im Sinne eines Bounded Context und damit unterschiedliche Sichten auf ein Geschäfts- objekt mit eigenen Daten haben.
 * Teilnehmer verstehen, dass zur Erreichung von höherer Autonomie der Entwicklungsteams ein Komponentenschnitt besser entlang fachlicher Grenzen anstatt entlang technischer Grenzen erfolgt.
-* Transaktionale Konsistenz lässt sich über Prozessgrenzen hinweg nur über zusätzliche Mechanismen erreichen. Wird ein System in mehrere Prozesse aufgeteilt, so stellt die Modulgrenze daher häufig auch die Grenze für transaktionale Konsistenz dar. Daher muss ein DDD-Aggre- gat in einem Modul verwaltet werden.
+* Transaktionale Konsistenz lässt sich über Prozessgrenzen hinweg nur über zusätzliche Mechanismen erreichen. Wird ein System in mehrere Prozesse aufgeteilt, so stellt die Modulgrenze daher häufig auch die Grenze für transaktionale Konsistenz dar. Daher muss ein DDD-Aggregat in einem Modul verwaltet werden.
 * Teilnehmer verstehen, welche Modularisierungskonzepte nicht nur für Transaktions-, sondern auch für Batch- und Datenfluss-orientierte Systeme genutzt werden können.
 
 .Was sollen die Teilnehmer kennen?

docs/03-integration/02-learning-goals.adoc

@@ -4,7 +4,7 @@
 [[LZ-3-1]]
 ==== LZ 3-1: Strategic Design
 
-1. Die Teilnehmer sollen ein grundlegendes Verständnis für die Umsetzung von Integrationen mit Hilfe 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.
+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.
 
 
@@ -19,17 +19,17 @@
 . RPC bezeichnet Mechanismen, um Funktionalität in einem anderen Prozess über Rechnergrenzen hinweg synchron aufzurufen. Dadurch entsteht Kopplung in vielerlei Hinsicht (zeitlich, Datenformat, API). Diese Kopplung hat negative Auswirkungen auf Verfügbarkeit und Antwortzeiten des Systems. REST macht Vorgaben, die diese Kopplung reduzieren können (Hypermedia, standardisierte API). Die zeitliche Kopplung bleibt jedoch grundsätzlich bestehen.
 . Bei der Integration mittels Messaging kommunizieren Systeme durch den asynchronen Austausch von Nachrichten. Die Systeme werden somit zeitlich entkoppelt. Technisch wird dies mittels Indirektion über eine Middleware erreicht. 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 Front-End-Integration sowie deren Vor- und Nachteile und Anwendbarkeit abhängig von Kontextkriterien benennen können.
+. 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.
+. 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 Micro- oder eine Macro-Architecture Entscheidung ist resp. ob sie die Entscheidung allein treffen können oder team-externe Stakeholder in den Entscheidungsprozess einbeziehen müssen
+. 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]]

docs/04-rollout/02-learning-goals.adoc

@@ -10,12 +10,12 @@
   * Die Teilnehmer sollen auf Basis des DevOps-Organisationsmodells einen Team-Aufbau skizzieren können.
 
 .Was sollen die Teilnehmer verstehen?
-  * Basis für die Automatisierung eines Deployments sind Virtualisierung oder Cloud mit Infra- structure as a Service (IaaS). Eine leichtgewichtige Alternative sind Linux-Container, wie sie Docker umsetzt.
+  * Basis für die Automatisierung eines Deployments sind Virtualisierung oder Cloud mit Infrastructure as a Service (IaaS). Eine leichtgewichtige Alternative sind Linux-Container, wie sie Docker umsetzt.
   * Ohne eine Deployment-Automatisierung ist das Deployment einer großen Anzahl von Servern und Services praktisch nicht möglich.
-  * Moderne Deployment-Werkzeuge ermöglichen es, auf Rechnern Software automatisiert zu installieren. Neben der Anwendung selbst kann dabei auch die vollständige Infrastruktur au- tomatisiert aufgebaut werden. Dabei sind die Installationen idempotent, d. h. sie führen un- abhängig vom Ausgangszustand des Systems immer zum gleichen Ergebnis.
+  * Moderne Deployment-Werkzeuge ermöglichen es, auf Rechnern Software automatisiert zu installieren. Neben der Anwendung selbst kann dabei auch die vollständige Infrastruktur automatisiert aufgebaut werden. Dabei sind die Installationen idempotent, d. h. sie führen unabhängig vom Ausgangszustand des Systems immer zum gleichen Ergebnis.
   * Immutable Server werden grundsätzlich nie geändert. Muss eine neue Version der Software in Betrieb genommen werden, wird der Server komplett neu aufgebaut. Das kann einfacher und zuverlässiger sein, als sich auf idempotente Werkzeuge zu verlassen.
   * PaaS (Platform as a Service) stellt eine vollständige Plattform bereit, in die Anwendungen deployt werden können. Da in diesem Fall die Infrastruktur nicht selber aufgebaut wird, ist der Ansatz einfacher, aber auch weniger flexibel.
-  * Konzepte wie Tests oder Code Reviews sind auch für die Deployment-Automatisierung unab- dingbar. Infrastruktur wird zu Code, der denselben Anforderungen wie produktiver Code ge- recht werden muss (Infrastructure as Code).
+  * Konzepte wie Tests oder Code Reviews sind auch für die Deployment-Automatisierung unabdingbar. Infrastruktur wird zu Code, der denselben Anforderungen wie produktiver Code gerecht werden muss (Infrastructure as Code).
   * Um das Deployment zu unterstützen, kann das Ergebnis eines Build-Prozesses Packages für ein Betriebssystem oder gar Images für virtuelle Maschinen sein.
   * Die Umgebungen eines Entwicklers sollten idealerweise mit den Umgebungen in Produktion übereinstimmen. Mit modernen Werkzeugen ist es möglich, eine solche Umgebung auf Knopfdruck zu erzeugen und aktuell zu halten.
   * Die Komplexität des Deployments wird zu einem weiteren Qualitätsmerkmal des Systems und beeinflusst Architektur-Werkzeuge.
@@ -26,7 +26,7 @@
     Delivery“).
 
 .Was sollen die Teilnehmer kennen?
-  * Grundlegende Konzept von moderner Infrastruktur wie IaaS, PaaS und Virtualisierung
+  * Grundlegendes Konzept von moderner Infrastruktur wie IaaS, PaaS und Virtualisierung
   * Konzepte von Deployment-Werkzeuge wie Chef, Puppet, Ansible oder Salt
   * Organisationsformen für DevOps
   * Konzept von Deployments mit Package-Managern oder Linux Containern

docs/05-operations/02-learning-goals.adoc

@@ -6,7 +6,7 @@
 ==== LZ 5-1: Fehleranalyse in verteilten Systemen
 
 .Was sollen die Teilnehmer können?
-  * Die Teilnehmer sollen ein Konzept grob skizzieren und verstehen können, auf dessen Basis ein System überwacht werden kann d. h. den aktuellen Status zu beurteilen, Fehler und Abweichungen vom normalen Betrieb möglichst zu vermeiden oder zumindest so früh wie möglich zu erkennen zu behandeln.
+  * Die Teilnehmer sollen ein Konzept grob skizzieren und verstehen können, auf dessen Basis ein System überwacht werden kann, d.h. den aktuellen Status zu beurteilen, Fehler und Abweichungen vom normalen Betrieb möglichst zu vermeiden oder zumindest so früh wie möglich zu erkennen zu behandeln.
 
 .Was sollen die Teilnehmer verstehen?
   * Die richtige Auswahl von Daten ist zentral für ein zuverlässiges und sinnvolles Monitoring und Logging.

docs/06-case-study/02-learning-goals.adoc

@@ -7,5 +7,5 @@ Die Case Study soll keine neuen Lernziele vermitteln, sondern die Themen durch p
 // end::DE[]
 
 // tag::EN[]
-The Case Study shall not introduce additional learning goals, but intesify the topics via practically relevant exercises.
+The Case Study shall not introduce additional learning goals, but intensify the topics via practically relevant exercises.
 // end::EN[]