Add more patterns to glossary

docs/1-terms/A/term-architecture-pattern.adoc

@@ -8,9 +8,9 @@
 
 Examples include:
 
-* Layers
-* Pipes-and-Filter
-* Microservices
+* <<term-layer,Layers>>
+* <<term-pipes-and-filters,Pipes and filters>>
+* <<term-microservice,Microservices>>
 * <<term-cqrs,CQRS>>
 
 // end::EN[]
@@ -27,9 +27,9 @@ ihnen (<<buschmann1996>>, Seite 12). Vergleichbar mit <<term-architecture-style,
 
 Beispiele:
 
-* Model-View-Controller
-* Schichten
-* Pipes und Filter
+* <<term-layer,Layers>>
+* <<term-pipes-and-filters,Pipes und Filter>>
+* <<term-microservice,Microservices>>
 * <<term-cqrs,CQRS>>
 
 // end::DE[]

docs/1-terms/B/0-structure.adoc

@@ -1,6 +1,7 @@
 
 === B
 
+include::term-blackboard.adoc[{include_configuration}]
 include::term-blackbox.adoc[{include_configuration}]
 include::term-bottom-up.adoc[{include_configuration}]
 include::term-bounded-context.adoc[{include_configuration}]

docs/1-terms/B/term-blackboard.adoc

@@ -0,0 +1,24 @@
+[#term-blackboard]
+
+// tag::EN[]
+
+==== Blackboard
+
+Architectural pattern that is useful for problems for which no
+deterministic solution strategies are known. In blackboard, several specialized subsystems
+assemble their knowledge to build a possibly partial or approximate solution.
+(Quoted from <<buschmann1996>>)
+
+// end::EN[]
+
+// tag::DE[]
+==== Blackboard
+
+Architekturmuster, welches oft für Probleme benutzt wird, die keine
+deterministische Lösungsstrategien erlauben. Mehrere spezialisierte Teilsysteme
+fügen im Blackboard
+ihr Wissen zusammen, um eine möglicherweise partielle oder ungefähre Lösung zu erarbeiten.
+(Zitiert aus <<buschmann1996>>)
+
+// end::DE[]
+

docs/1-terms/C/0-structure.adoc

@@ -13,6 +13,7 @@ include::term-cia-triad.adoc[{include_configuration}]
 include::term-cloud.adoc[{include_configuration}]
 include::term-co-existence-quality-attribute.adoc[{include_configuration}]
 include::term-cohesion.adoc[{include_configuration}]
+include::term-combinator.adoc[{include_configuration}]
 include::term-command.adoc[{include_configuration}]
 include::term-common-closure-principle.adoc[{include_configuration}]
 include::term-common-reuse-principle.adoc[{include_configuration}]

docs/1-terms/C/term-combinator.adoc

@@ -0,0 +1,25 @@
+[#term-combinator]
+
+// tag::EN[]
+==== Combinator
+
+Design pattern to build complex functions or objects by combining simpler ones.
+For some domain object of type T, look for operations with both input and output type T.
+Also know as _closure of operation_.
+See <<yorgey>> and <<maguire>>.
+
+// end::EN[]
+
+// tag::DE[]
+==== Kombinator
+
+Entwurfsmuster zum Aufbau komplexer Funktionen oder Objekte durch die Kombination
+einfacherer Funktionen oder Objekte.
+Gegeben ein Domänenobjekt vom Typ T, suche nach Operationen,
+die als Ein- und Ausgabe ebenfalls den Typ T haben.
+Auch bekannt als _closure of operation_.
+Siehe <<yorgey>> und <<maguire>>.
+
+// end::DE[]
+
+

docs/1-terms/D/term-dependency-injection.adoc

@@ -6,15 +6,18 @@
 Instead of having your objects or a factory creating a dependency,
 you pass the needed dependencies to the constructor or via property setters.
 You therefore make the creation of specific dependencies _somebody else's problem_.
+Often used to ensure the <<term-dependency-inversion,dependency inversion principle>>.
 
 // end::EN[]
 
 // tag::DE[]
 ==== Abhängigkeitsinjektion / Dependency Injection (DI)
 
-Statt dass Ihre Objekte oder eine Fabrik eine Abhängigkeit erzeugen,
-übergeben Sie die benötigten Abhängigkeiten an den Konstruktor oder
-über Eigenschaft-Setter. Damit machen Sie die Erzeugung
+Objekte erzeugen abhängige Objekte nicht selbst, stattdessen werden
+die benötigten Abhängigkeiten an den Konstruktor übergeben oder via
+Setter gesetzt. Damit wird die Erzeugung
 von spezifischen Abhängigkeiten zum _Problem anderer Leute_.
+Wird oft benutzt um das
+<<term-dependency-inversion,Abhängigkeits-Umkehr-Prinzip>> sicherzustellen.
 
 // end::DE[]

docs/1-terms/E/0-structure.adoc

@@ -10,3 +10,4 @@ include::term-enterprise-it-architecture.adoc[{include_configuration}]
 include::term-entity.adoc[{include_configuration}]
 include::term-entropy.adoc[{include_configuration}]
 include::term-environment.adoc[{include_configuration}]
+include::term-event-sourcing.adoc[{include_configuration}]

docs/1-terms/E/term-event-sourcing.adoc

@@ -0,0 +1,23 @@
+[#term-event-sourcing]
+
+// tag::EN[]
+
+==== Event Sourcing
+
+Architecture pattern where changes to the application's state are
+captured as a series of immutable events. Instead of storing just the current state of the
+application,  every state change is recorded as an event in an append-only log.
+
+// end::EN[]
+
+// tag::DE[]
+
+==== Event Sourcing
+
+Architekturmuster, bei dem Änderungen am Zustand der Anwendung
+als eine Serie von unveränderlichen Ereignissen erfasst werden. Anstatt nur den aktuellen
+Zustand der Anwendung zu speichern, wird jede Zustandsänderung als Ereignis
+in einem "append-only"-Log festgehalten.
+
+
+// end::DE[]

docs/1-terms/F/term-filter.adoc

@@ -3,9 +3,9 @@
 // tag::EN[]
 ==== Filter
 
-Part of the pipe-and-filter architectural style that creates or transforms data.
+Part of the pipes and filters architectural style that creates or transforms data.
 Filters are typically executed independently of other filters.
-
+See <<term-pipes-and-filters, pipes and filters>>.
 
 // end::EN[]
 
@@ -15,7 +15,7 @@ Filters are typically executed independently of other filters.
 Teil des "Pipes und Filter"-Architekturstils, der Daten erzeugt oder
 transformiert. Filter werden üblicherweise unabhängig von anderen
 Filtern ausgeführt.
-
+Siehe <<term-pipes-and-filters, Pipes und Filter>>
 
 
 // end::DE[]

docs/1-terms/I/0-structure.adoc

@@ -12,6 +12,7 @@ include::term-integrity.adoc[{include_configuration}]
 include::term-interface-segregation-principle.adoc[{include_configuration}]
 include::term-interface.adoc[{include_configuration}]
 include::term-interoperability-quality-attribute.adoc[{include_configuration}]
+include::term-interpreter.adoc[{include_configuration}]
 include::term-isaqb.adoc[{include_configuration}]
 include::term-iso-25010.adoc[{include_configuration}]
 include::term-iso-9126.adoc[{include_configuration}]

docs/1-terms/I/term-interpreter.adoc

@@ -0,0 +1,20 @@
+[#term-interpreter]
+
+// tag::EN[]
+==== Interpreter
+
+Design pattern that represents domain objects or domain-specific languages as syntax.
+An interpreter function then provides a semantic interpretation of domain objects separately
+from the objects.
+
+// end::EN[]
+
+// tag::DE[]
+
+==== Interpreter
+
+Entwurfsmuster, das Domänenobjekte oder domänenspezifische Sprachen als Syntax darstellt.
+Eine Interpreterfunktion liefert dann eine semantische Interpretation der Domänenobjekte getrennt
+von den Objekten.
+
+// end::DE[]

docs/1-terms/L/term-layer.adoc

@@ -6,14 +6,25 @@
 Grouping of building blocks or components that (together) offer a
 cohesive set of services to other layers.
 Layers are related to each other by the ordered relation _allowed to use_.
+Two common kinds of layers are _abstraction layers_ to hide details
+(example: ISO/OSI network layers, or "hardware abstraction layer",
+see https://en.wikipedia.org/wiki/Hardware_abstraction) and layers that
+(physically) separate functionality or responsibility
+(see https://en.wikipedia.org/wiki/Multitier_architecture).
 
 // end::EN[]
 
 // tag::DE[]
 ==== Schicht
 
-Zusammenstellung von Bausteinen oder Komponenten die (zusammen) anderen Schichten einen kohärenten Satz an Services bieten. Die Beziehung zwischen Schichten wird durch die geordnete Beziehung _erlaubt zu nutzen_ geregelt.
-
+Zusammenstellung von Bausteinen oder Komponenten die (zusammen) anderen Schichten
+einen kohärenten Satz an Services bieten. Die Beziehung zwischen Schichten wird
+durch die geordnete Beziehung _erlaubt zu nutzen_ geregelt.
+Zwei häufigen Arten von Schichten sind _Abstraktionschichten_ zum Verstecken von Details
+(Beispiel: ISO/OSI-Netzwerkschichten oder „Hardware-Abstraktionsschicht“,
+siehe https://en.wikipedia.org/wiki/Hardware_abstraction) und Schichten, die
+(physikalisch) Funktionen oder Verantwortlichkeiten trennen
+(siehe https://de.wikipedia.org/wiki/Schichtenarchitektur).
 
 
 // end::DE[]

docs/1-terms/M/0-structure.adoc

@@ -11,6 +11,8 @@ include::term-model-driven-architecture.adoc[{include_configuration}]
 include::term-model-driven-software-development.adoc[{include_configuration}]
 include::term-model-kind.adoc[{include_configuration}]
 include::term-model-view-controller.adoc[{include_configuration}]
+include::term-model-view-update.adoc[{include_configuration}]
+include::term-model-view-viewmodel.adoc[{include_configuration}]
 include::term-modeling-tool.adoc[{include_configuration}]
 include::term-modifiability-quality-attribute.adoc[{include_configuration}]
 include::term-modular-programming.adoc[{include_configuration}]

docs/1-terms/M/term-model-view-controller.adoc

@@ -1,10 +1,10 @@
 [#term-model-view-controller]
 
 // tag::EN[]
-==== Model-View-Controller
+==== Model-View-Controller (MVC)
 
 Architecture pattern, often used to implement user interfaces. It divides a
-system into three interconnected parts (model, view and controller) to separate
+system into three interconnected parts (model, view, and controller) to separate
 the following responsibilities:
 
 * Model manages data and logic of the system. The "truth" that will be shown or
@@ -17,16 +17,20 @@ the following responsibilities:
 // end::EN[]
 
 // tag::DE[]
-==== Model-View-Controller
+==== Model-View-Controller (MVC)
 
 Architekturmuster, das häufig zur Implementierung von
 Benutzeroberflächen verwendet wird. Unterteilt ein System in drei
 miteinander verbundene Teile (Modell / model, Präsentation / view und
 Steuerung / controller), um die folgenden Verantwortlichkeiten zu
 trennen:
 
-* Das Modell verwaltet Daten und Logik des Systems. Die "Wahrheit", die von einer oder vielen Präsentationen gezeigt oder angezeigt wird. Das Modell kennt seine Präsentationen nicht (und ist nicht von ihnen abhängig).
-* Die Präsentation kann eine Reihe von (beliebigen) Output-Darstellungen der (Modell-)Informationen sein. Mehrere Präsentationen desselben Modells sind möglich.
-* Die Steuerung akzeptiert (Benutzer-)Eingaben und wandelt diese in Befehle für das Modell oder die Präsentation um.
+* Das Modell verwaltet Daten und Logik des Systems. Die "Wahrheit", die von einer oder vielen
+Präsentationen gezeigt oder angezeigt wird. Das Modell kennt seine Präsentationen nicht
+(und ist nicht von ihnen abhängig).
+* Die Präsentation kann eine Reihe von (beliebigen) Output-Darstellungen der
+(Modell-)Informationen sein. Mehrere Präsentationen desselben Modells sind möglich.
+* Die Steuerung akzeptiert (Benutzer-)Eingaben und wandelt diese in Befehle für das
+Modell oder die Präsentation um.
 
 // end::DE[]

docs/1-terms/M/term-model-view-update.adoc

@@ -0,0 +1,26 @@
+[#term-model-view-update]
+
+// tag::EN[]
+==== Model-View-Update (MVU)
+
+Architecture pattern, often used to implement user interfaces. It emphasizes immutability
+and unidirectional data flow. It consists of three parts:
+
+* Model represents the application's state as an immutable data structure.
+* View is a function without side effects for rendering the model in the UI.
+* Update is a function that handles updates on the model by producing a new model instance.
+
+// end::EN[]
+
+// tag::DE[]
+==== Model-View-Update (MVU)
+
+Architekturmuster, das häufig zur Implementierung von Benutzeroberflächen verwendet wird.
+Es beruht auf unveränderbaren Daten und unidirektionalem Datenfluss. Es besteht aus drei Teilen:
+
+* Model repräsentiert den Zustand der Anwendung als unveränderbare Datenstruktur.
+* View ist eine Funktion ohne Seiteneffekte, die das Model in der UI darstellt.
+* Update ist eine Funktion, die Aktualisierungen des Models verarbeitet,
+indem sie eine neue Instanz des Models erzeugt.
+
+// end::DE[]

docs/1-terms/M/term-model-view-viewmodel.adoc

@@ -0,0 +1,33 @@
+[#term-model-view-viewmodel]
+
+// tag::EN[]
+==== Model-View-ViewModel (MVVM)
+
+Architecture pattern, often used to implement user interfaces. It divides a
+system into three interconnected parts (model, view, and view model) to separate
+the following responsibilities:
+
+* Model manages data and domain logic of the system. Does not depend on the view
+and the view model.
+* View is the visible user interface of the application (or parts thereof).
+* ViewModel serves as an intermediary between the View and the Model and holds the UI logic.
+May depend on the model but not on the view.
+
+
+
+// end::EN[]
+
+// tag::DE[]
+==== Model-View-ViewModel (MVVM)
+
+Architekturmuster, das häufig zur Implementierung von Benutzeroberflächen verwendet wird.
+Es unterteilt eine Anwendung in drei Teile (Model, View, und ViewModel):
+
+* Model verwaltet die Daten und die Domänenlogik des Systems. Hängt nicht von View
+und ViewModel ab.
+* View ist die sichtbare Benutzeroberfläche der Anwendung (oder Teilen davon).
+* ViewModel dient als Vermittler zwischen View und Model und enthält die UI-Logik.
+Kann vom Model abhängen, aber nicht vom View.
+
+
+// end::DE[]

docs/1-terms/P/0-structure.adoc

@@ -10,10 +10,14 @@ include::term-performance-efficiency-quality-attribute.adoc[{include_configurati
 include::term-perspective.adoc[{include_configuration}]
 include::term-pikachu.adoc[{include_configuration}]
 include::term-pipe.adoc[{include_configuration}]
+include::term-pipes-and-filters.adoc[{include_configuration}]
 include::term-pki.adoc[{include_configuration}]
+include::term-plugin.adoc[{include_configuration}]
 include::term-port.adoc[{include_configuration}]
 include::term-portability-quality-attribute.adoc[{include_configuration}]
+include::term-ports-and-adapters.adoc[{include_configuration}]
 include::term-posa.adoc[{include_configuration}]
+include::term-presentation-abstraction-control.adoc[{include_configuration}]
 include::term-principal.adoc[{include_configuration}]
 include::term-proxy.adoc[{include_configuration}]
 include::term-pseudo-randomness.adoc[{include_configuration}]

docs/1-terms/P/term-pipe.adoc

@@ -6,6 +6,7 @@
 Connector in the pipes-and-filters architectural style that transfers
 streams or chunks of data from the output of one filter to the input
 of another filter without modifying values or order of data.
+See <<term-pipes-and-filters, pipes and filters>>.
 
 
 // end::EN[]
@@ -17,6 +18,7 @@ Verbindung im "Pipes und Filter"-Architekturstil, die Datenströme oder
 -blöcke von der Ausgabe eines Filters zur Eingabe eines anderen
 Filters überträgt, ohne Werte oder die
 Datenreihenfolge zu verändern.
+Siehe <<term-pipes-and-filters, Pipes und Filter>>
 
 
 

docs/1-terms/P/term-pipes-and-filters.adoc

@@ -0,0 +1,23 @@
+[#term-pipes-and-filters]
+
+// tag::EN[]
+==== Pipes and Filters
+
+The Pipes and Filters architectural pattern provides a structure for systems that process
+a stream of data. Each processing step is encapsulated in a filter component. Data is
+passed through pipes between adjacent filters. Recombining filters allows you to
+build families of related systems. (Quoted from <<buschmann1996>>, also see <<term-pipe,pipe>> and
+<<term-filter,filter>>.)
+
+// end::EN[]
+
+// tag::DE[]
+==== Pipes und Filter
+
+Das Architekturmuster "Pipes und Filter" bietet eine Struktur für Systeme, die Datenströme
+verarbeiten. Jeder Verarbeitungsschritt wird als eine Filterkomponente gekapselt, dabei werden
+die Daten zwischen benachbarten Filtern durch Pipes geleitet. Andere Kombinationen
+der Filter führt zu einer Variente des Systems. (Zitiert aus <<buschmann1996>>,
+siehe auch <<term-pipe,Pipe>> und <<term-filter,Filter>>.)
+
+// end::DE[]