Decision Log

Hier werden alle getroffenen Architekurentscheidungen festgehalten. Als zeitliche Anhaltspunkte sind die getroffenen Entscheidungen jeweils in die Zeiträume zwischen zwei Veranstaltungen von FAE eingeteilt. Die Auflistung ist zudem chronologisch rückwärts von neu zu alt sortiert.

Fr, 01.02.2019:

Context Map (Version 6)

• Erstellung des Domain Models

Fr, 25.01.2019:

Frontend / UI

• Ein Microfrontend (Headfull Microservices mit einer Shared UI) bietet die meisten Vorteile

Fr, 18.01.2019:

Frontend / UI

• Open Street Map soll in der Zukunft aus Kostengründen verwendet werden

Gut strukturierter Monolith oder Zusammenspiel mehrerer Microservices?

Im aktuellen Projektzustand ist es nicht notwenig eine Entscheidung zu treffen, da in der behandelten Subdomäne momentan nur ein MS existiert. Dieser ist auch als ein strukturierter Monolith darstellbar. Sollte die Subdomäne "wachsen" würde an diesem Punkt erneut entschieden werden, welche Struktur besser geeignet ist.

Client - Strategische oder Taktische Architektur Entscheidung?

Die Clientarchitektur Auswahl ist in jedem Fall eine strategische Entscheidung. Im folgenden wird dies für die verschiedenen Clientarchitekturen erläutert.

• Big UI: Eine UI für alle Teams
• Little frontends: Einige Teams teilen sich eine UI
• Decomposed UI/Shared UI: Eine gemeinsame Clienttechnologie

Die Serverarchitektur kann in den jeweiligen Subdomänen einzeln entschieden, deswegen ist hier nur eine taktische Architekturwahl notwenig.

Somit ist davon auszugehen, dass in der Systemlandschaft beide Architekturen (MS-Architektur, gut strukturierter Monolith) enthalten sind. Bei den gut strukturierten Monolithen muss verstärkt berücksichtigt werden, dass die Unabhängigkeit der anderen MS weiterhin gewährleisten ist und somit keine Abhängigkeiten produziert werden.

Fr, 11.01.2019:

Frontend / UI

• Wir benötigen im Frontend geographische Daten (Karten) und haben hierzu die Google Maps API und Open Street Map evaluiert.
• 2 UI-Elemente wurden erstellt:
  • Gebietsverwaltung - Karteneditor zum einsehen und verändern von Routen und Orten einer DVP
  • Aktuelle Position - Repräsentation eines ungewöhnlichen bzw. des derzeitigen Aufenthaltortes einer DVP im Kontext der Erkennung eines ungewöhnlichen Aufenthaltsortes

Fr, 21.12.2018:

Context Map (Version 5)

• Entwicklung des Microservice Standortverlauf eingestellt, somit bleibt nur noch ein Microservice Ungewöhnlicher Aufenthaltsort
• Die Entity Bezugsperson und das Value Object Geofence wird entfernt

Kategorisierung von Orten & Routen

Um eine eindeutige Entscheidung treffen zu können, sollen Routen & Orte nicht mehr Black- & Whitelistbar sein. Angelegte Routen und Orte sind somit automatisch als unbedenklich/normal (Whitelisted) zu verstehen. Jeder nicht gekennzeichnete Aufenthaltsort ist im Umkehrschluss als ungewöhnlich (Blacklist) definiert. Ist für eine DVP keine Route oder ein Ort angelegt, so findet auch keine Prüfung nach einem ungewöhnlichen Aufenthaltsort statt, jeder Aufenthaltsort ist somit unbedenklich/normal (Whitelisted).

Fr, 14.12.2018:

Wahl der Datenbank

Harte Anforderung ist die Verwendung, für die Teilnehmer der Veranstaltung, einer kostenlosen Datenbank. Die Datenbank muss containerisierbar sein. Die Datenbank darf kein Exot sein, damit sich jeder schnell einarbeiten kann und gute Dokumentation sowie Beispiele vorhanden sind. Die Datenbank sollte (gute) Unterstützung für geographische Daten bieten. Die Datenbank sollte graphische Entwicklungstools anbieten. Zur Auswahl stehen:

• MariaDB
• PostgresSQL
• Microsoft SQL Server

Alle genannten Datenbanken erfüllen die harten Kriterien. Es bestehen bei keiner Datenbank Bedenken hinsichtlich der Leistungsfähigkeit. PostgresSQL bietet mit PostGIS die umfangreichsten Funktionen im Bereich der Geodaten. Aus diesem Grund ist die Wahl auf PostgresSQL gefallen.

Fr, 07.12.2018:

Execution Environment / Docker

Services nun als Docker Container deploybar, zur Orchestrierung von HTTP aufrufen zwischen mehreren Instanzen der Services wird HAProxy als Loadbalancer eingesetzt.

Fr, 30.11.2018:

Context Map (Version 4)

• Umbenennung des Microservices Lokation Historie in Standortverlauf
• Umbenennung des Microservices Route / Ort in Ungewöhnlicher Aufenthaltsort
• Umbenennung des Services Notlagenerkennung in Ungewöhnliche Aufenthaltsorte erkennen

REST

Der Microservice Standortverlauf muss keine gesonderten Anfragen für die Domäne Ungewöhnliches Verhalten bereitstellen, wie z.B.: Welche DVP waren im Zeitraum Z an Position P im gewissen Umkreis U?

Fr, 16.11.2018:

Monorepository oder Multirepository?

Wir haben uns dazu entschieden, dass wir innerhalb unseres Teams ein Monorepository betreiben möchten, da ein Repository unserer Meinung nach völlig ausreichend ist (Code wird am Ende nicht so groß werden, dass ein Repository nicht ausreichen würde). Unsere beiden Microservices sind dann in jeweils einem eigenen Verzeichnis beheimatet.

Getroffene Entscheidung + Begründung ergänzen!

Fr, 09.11.2018:

Context Map (Version 3)

• Anlaufstellen gehören nicht mehr zu unserer Subdomäne, somit kann das Value Object Kontaktdaten entfernt werden
• Der Microservice Route und der Microservice Ort werden zusammen geführt, somit gibt es nur noch die zwei Microservices Ort/Route und Historischen Lokation

HATEOAS

Wir verwenden HATEOAS in Form von HAL, die eingebetteten Links erscheinen uns sinnvoll und nützlich. Dass der Client dadurch kein Domänenwissen mehr benötigt, sehen wir nicht. Da im Kontext der Veranstaltung kein Client entwickelt werden soll, kann es zu diesem Thema unserer Meinung nach auch keine zielführende Konversation, z.B. mit einem etwaigen Frontend-Team zustande kommen. Ein weiteres Gegenargument wäre, dass die strikte Einhaltung einen zu unflexiblen und statischen Client hervorrufen könnte.

Fr, 02.11.2018:

Context Map (Version 2)

• Im weiteren Verlauf werden nur noch folgende Elemente betrachtet: Entity, Value Object, Aggregates, Aggregate Root
  • Aggregate Root mit den Bestandteilen des Aggregates
    • Ort: Geofence, Lokation, Kontaktdaten, DVP, Bezugsperson
    • Route: Lokation, DVP, Bezugsperson
    • Historische Lokation: Lokation, Zeitpunkt, DVP, Bezugsperson
  • Value Object: Kontaktdaten, Geofence, Lokation, Zeitpunkt
  • Entity: Ort, Route, Historische Lokation, DVP, Bezugsperson
• Jedes Aggregate Root wird in einem eigenem Micro-Service implementiert, somit entstehen 3 Micro-Services

Fr, 26.10.2018:

Context Map (Version 1)

Folgende Elemente wurden in der ersten Version gefunden und definiert:

• Entity: DVP, Ort, Route
• Value Object: Geofence, Kontaktdaten, Lokation
• Repository: Orte, Routen, LokationHistorie
• Service: Überwachung, Notification/Alert, Ortung

Ubiquitous Language

• Wir haben uns dazu entschieden, eine übergreifende Ubiquitous Language für alle relevanten Elemente unserer Sub-Domäne zu erstellen und nicht wie häufig propagiert, eine eigene Ubiquitous Language für jeden Bounded Context.