Add English translation.

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

@@ -53,7 +53,7 @@ Die Ausgestaltung der Beispiele und Übungen sind in diesem Lehrplan nicht vorge
 // tag::EN[]
 === Curriculum Structure and Recommended Durations
 
-[cols="<,>", options="header"]
+[cols="<,>,>", options="header"]
 |===
 | Content
 | Recommended duration (minutes)

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

@@ -23,18 +23,26 @@ Herausforderungen.
 // tag::EN[]
 === Prerequisites
 
-TODO
-Participants **should** have the following prerequisite knowledge:
-
-- Prerequisite 1
-- Prerequisite 2, etc.
-
-Knowledge in the following areas may be **helpful** for understanding some concepts:
-
-- Area 1:
-  * Knowledge 1
-  * Experience 2
-  * Knowledge 3
-  * Experience 4
-  * Understanding 5
+Participants **should** have the following knowledge and / or
+experience:
+
+- Fundamentals of the description of architectures using various
+  views, comprehen- sive concepts, design decisions, boundary conditions
+  etc., as taught in the CPSA-F (Foundation Level).
+- Experience with implementation and architecture in agile projects.
+- Experiences from the development and architecture of classical systems with the
+  typical challenges.
+
+**Useful** for understanding some concepts are also:
+
+- Distributed systems
+  * Problems and challenges in the implementation of distributed
+    systems
+  * Typical distributed algorithms
+  * Internet protocols
+
+- Knowledge about modularisations
+  * Functional modularisation
+  * Technical implementations like packages or libraries
+- Classical operation and deployment processes
 // end::EN[]

docs/01-motivation/01-duration-terms.adoc

@@ -13,5 +13,5 @@ Verfügbarkeit, Zuverlässigkeit, Time-to-Market, Flexibilität, Vorhersagbarkei
 |===
 
 === Terms and Principles
-Availability, resilience, time-to-market, flexibility, predictability, reproducibility, homogenization of stages, internet/web scale, distributed systems, parallelizing feature development, evolution of architecture (build for replacement), heterogenity, automation
+Availability, resilience, time-to-market, flexibility, predictability, reproducibility, homogenization of stages, internet/web scale, distributed systems, parallelizing feature development, evolution of architecture (build for replacement), heterogenity, automation.
 // end::EN[]

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

@@ -27,7 +27,7 @@ Sie haben die Kompromisse der vorgestellten Architektur-Typen (mindestens Micros
 [[LZ-1-4]]
 ==== LZ 1-4: Verständnis für Rahmenbedingungen von verteilten Systemen
 
-.Teilnehmer sollen Rahmenbedingungen von verteilten Systemen verstehen, wie z.B. 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.
@@ -52,8 +52,81 @@ Sie haben die Kompromisse der vorgestellten Architektur-Typen (mindestens Micros
 
 // tag::EN[]
 [[LG-1-1]]
-==== LG 1-1: This is the first learning goal, in category xy
-tbd.
+==== LG 1-1: Quality goals of flexible architectures
+
+Architectures can be optimised to meet different quality goals.
+
+In this module participants learn how to develop architectures that
+allow fast deployment and fast feedback from using the system.  Such
+architectures support developers in achieving functional suitability
+efficiently and improve usability.  They also foster modularity and
+can serve to achieve high reliability und replace individual
+components in isolation, which serves flexibility.
+
+[[LG-1-2]]
+==== LG 1-2: Interaction of architecture types and organisation
+They have understood the drivers for the architecture types taught in
+this curriculum module, the implications of these drivers for the
+architectures, and the interaction of the architectures with the
+organisation, processes, and technologies.
+
+[[LG-1-3]]
+==== LG 1-3: Communicating and adapting compromises of the presented architecture types
+
+They have understood the trade-offs of the architecture types
+presented (at least Microservices, Self-Contained Systems and
+Deployment Monoliths) and are able to communicate them as well as
+apply them in the context of concrete projects / system developments
+in order to make appropriate architectural decisions.
+
+[[LG-1-4]]
+==== LG 1-4: Understanding the constraints of distributed systems
+
+.Participants understand the constraints of distributed systems, such as the following:
+
+  * The architecture has crucial influence on the ability to quickly
+    bring new features into production.
+  * Dependencies between components of different development teams
+    influence the duration until software can be put into production
+    because they increase the communication costs and delays are
+    propagated.
+  * Automation of activities (such as test and deployment processes)
+    increases the reproducibility, predictability, and quality of
+    results of these processes. This can lead to an improvement of the
+    overall development process.
+  * Unification of the different environments (e.g., development,
+    test, QA, production) reduces the risk of lately detected and (in
+    other environments) non-reproducible errors due to different
+    configurations.
+  * Unification and automation are essential aspects of continuous
+    delivery.
+  * Continuous integration is a prerequisite for continuous
+    delivery.
+  * A suitable architecture is the prerequisite for the
+    parallelization of the development as well as the independent
+    commissioning of independent modules. This can, but do not have to
+    be "services".
+  * Some change scenarios are easier to implement in monolithic
+    architectures. Other change scenarios are easier to implement in
+    distributed service architectures. Both approaches can be
+    combined.
+  * There are different types of isolation with different
+    advantages. A failure, for example, can be limited to a single
+    component or changes can be limited to a single component.
+  * Certain types of isolation are much easier to implement between
+    processes with remote communication.
+  * Remote communication, however, has disadvantages - for example
+    many new sources of errors.
+
+[[LG-1-5]]
+==== LG 1-5: Contextualizing topics and buzzwords
+
+  * Conway’s law
+  * Partitionability as a quality feature
+  * Round trip times with the IT supply chain as a competitive factor
+  * Building a continuous delivery pipeline
+  * The different test phases of a continuous delivery pipeline
+
 // end::EN[]
 
 

docs/02-modularization/01-duration-terms.adoc

@@ -19,6 +19,13 @@
 |===
 
 === Terms and Principles
-Term 1, Term 2, Term 3
+
+- Motivation for decompositioning into smaller systems
+- Different kinds of modularisation, coupling
+- System limits as a way of isolation
+- Hierarchical structure
+- Application, Self-Contained System, Microservice
+- Domain-Driven Design Concepts and "Strategic Design", Bounded Contexts
+
 
 // end::EN[]

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

@@ -32,7 +32,7 @@
 * Die Teilnehmer können ein Konzept erarbeiten, um ein System aus Services aufzubauen.
 
 .Was sollen die Teilnehmer verstehen?
-* Modularisierung hilft Ziele wie Parallelisierung der Entwicklung, unabhängiges Deployment/Austauschbarkeit zur Laufzeit, Rebuild/Reuse von Modulen und leichtere Verständlich- keit des Gesamtsystems zu erreichen.
+* Modularisierung hilft Ziele wie Parallelisierung der Entwicklung, unabhängiges Deployment/Austauschbarkeit zur Laufzeit, Rebuild/Reuse von Modulen und leichtere Verständlichkeit des Gesamtsystems zu erreichen.
 * Daher ist beispielsweise Continuous Delivery und die Automatisierung von Test und Deployment ein wichtiger Einfluss auf die Modularisierung.
 * Modularisierung bezeichnet Dekomposition eines Systems in kleinere Teile. Diese Teile nach der Dekomposition wieder zu integrieren, verursacht organisatorische und technische Auf- wände. Diese Aufwände müssen durch die Vorteile, die durch die Modularisierung erreicht werden, mehr als ausgeglichen werden.
 * Je nach gewählter Modularisierungstechnologie besteht Kopplung auf unterschiedlichen Ebenen:
@@ -77,12 +77,167 @@
 
 // tag::EN[]
 [[LG-2-1]]
-==== LG 2-1: TBD
-tbd.
+==== LG 2-1: Decomposing into building blocks
+
+.What shall participants be capable of?
+
+* Participants can design a decomposition into individual blocks for a
+  given problem.
+* The participants should consider the organisation's communication
+  structure when setting the module boundaries (Conway's law).
+* The participants can draw up a plan to divide a deployment monolith
+  into small services.
+
+.What should participants understand?
+
+* Participants understand that each type of building blocks requires a handy label, as well as a description,
+** what makes up this kind of building block
+** how such a building block is integrated at runtime
+** how such a building block is built (in the sense of the build system)
+** how such a building block is deployed
+** how such a building block is tested
+** how such a building block is scaled
+* Different levels of specifications can be useful for the development
+  of a module. Some specifications should better be superior valid for
+  the integration with other building blocks of this type, in
+  general. The overarching decisions that affect all systems can
+  form a macro architecture, including, for example, communications
+  protocols or operating standards. Micro architecture can be the
+  architecture of a single system. It is largely independent of other
+  systems. Excessive limitations at the macro architecture level will
+  lead to an overall architecture that can be applied to fewer
+  problems
+
+.What should participants know?
+
+* The participants should know Conway’s law.
 
 [[LG-2-2]]
-==== LG 2-2: TBD
-tbd.
+==== LG 2-2: Modularisation concepts
+
+.What shall participants be capable of?
+
+* The participants should be able to evaluate and select technical
+  modularisation concepts in a project-specific manner.
+* The participants should be able to illustrate and analyse the
+  relationships between modules as well as between modules and
+  subdomains (context mapping).
+* Participants can develop a concept to build a system of services.
+
+.What should participants understand?
+
+* Modularisation helps to achieve goals such as parallelization of
+  development, independent deployment / interchangeability at runtime,
+  rebuild / reuse of modules and easier understanding of the overall
+  system.
+* Therefore, techniques like continuous delivery and the automation of
+  test and deployment are important influences on the modularisation.
+* Modularisation means the decomposition of a system into smaller
+  parts. Re-integrating these parts after the decomposition causes
+  organisational and technical efforts. These efforts have to be
+  exceeded by the advantages achieved by the modularisation.
+* Depending on the chosen modularisation technology, there is coupling
+  on different levels:
+** Sourcecode (modularisation with files, classes, packages,
+   namespaces etc.)
+** Built target (modularisation with JARs, libraries, DLLs, etc.)
+** Runtime environment (operating system, virtual machine or
+   container)
+** Network protocol (distribution to different processes)
+* A coupling at the source code level requires very close cooperation
+  as well as common SCM. A coupling at the level of the built target
+  means that the building blocks must usually be deployed
+  together. Only a distribution to different applications / processes
+  is feasible with regard to independent deployment.
+* Participants understand that a complete isolation between building
+  blocks can only be ensured by a separation in all phases
+  (development, deployment and runtime). If this is not the case,
+  undesirable dependencies cannot be excluded. At the same time, the
+  participants also understand that it can be useful to forego
+  complete isolation for reasons such as efficient resource usage or
+  complexity reduction.
+* Participants understand that, when distributing to different
+  processes, some dependencies no longer exist in the implementation,
+  but rather arise at runtime. This increases the requirements for
+  monitoring these interfaces.
+* Microservices are independent deployment units and therefore
+  independent processes that expose their functions through
+  lightweight protocols, but may also have a UI. Different technology
+  decisions can be made for the implementation of each individual
+  microservice.
+* A Self-Contained System (SCS) is a functionally independent
+  system. It usually includes UI and persistence. It may consist of
+  several Microservices. Usually a SCS covers a functional bounded
+  context.
+
+.What should participants know?
+* The participants should know various technical modularisation
+  options: e.g., source code files, libraries, frameworks, plugins,
+  applications, processes, Microservices, SCS.
+* The participants should know various technical modularisation
+  options: e.g., source files, libraries, frameworks, plugins,
+  applications, processes, microservices, self-contained systems
+* The participants should know "The Twelve-Factor App". 
+
+[[LG-2-3]]
+==== LG 2-3: Modularisation strategies
+
+.What shall participants be capable of?
+
+* Participants can evaluate the consequences of different
+  modularisation strategies and compare the efforts of the
+  modularisation with the expected benefits.
+* Participants can assess the impact of the modularisation strategy
+  on the autonomy of building blocks at development time and at run
+  time.
+* The participants can choose a suitable modularisation as well as a
+  suitable granularity of the modularisation - depending on the
+  organisation and the quality goals.
+
+.What should participants understand?
+
+* Participants understand that an integration strategy decides whether
+  a dependency 
+** emerges at runtime
+** emerges during development time, or
+** emerges at the deployment.
+* The module division can be done along functional or technical
+  boundaries. In most cases, a functional division is recommended,
+  because in this case functional requirements can be assigned more
+  clearly to a concrete module, and therefore it is not necessary to
+  adapt several modules for the implementation of a single functional
+  requirement. Thereby, each module can have its own domain model in
+  the sense of a bounded context and thus different views on a
+  business object with its own data.
+* Participants understand that in order to achieve higher autonomy of
+  the development teams, it is better to divide a component along
+  functional boundaries rather than along technical boundaries.
+* Transactional consistency through
+  process boundaries can only be achieved via additional
+  mechanisms. So, if a system is divided into several processes, the
+  module boundary often also represents the limit for transactional
+  consistency. Therefore, a DDD aggregate must be managed in one
+  module.
+* Participants understand which modularisation concepts can be used
+  not only for transactional but also for batch- and
+  data-flow-oriented systems.
+
+.What should participants know?
+
+* The participants should know the following terms from the
+  domain-driven design: Aggregate Root, Context Mapping, Bounded
+  Contexts and relationships between them (e.g., Anti-Corruption
+  Layer).
+
+
 // end::EN[]
 
 
+
+
+
+· 
+
+
+
+

docs/03-integration/01-duration-terms.adoc

@@ -14,6 +14,8 @@ Frontend Integration, Legacy Systeme, Authentifizierung, Autorisierung, (lose) K
 |===
 
 === Terms and Principles
-Term 1, Term 2, Term 3
+Frontend integration, legacy systems, authentication, authorisation,
+(loose) coupling, scalability, messaging patterns, domain events,
+decentralised data management.
 
 // end::EN[]