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

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

Fr, 16.11.2018:

Monorepository oder Multirepository?

Wir haben uns dazu entschieden, dass wir innerhalb unserers Teams ein Monorepository betreiben möchten. 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

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 so nicht. Ein weiteres Gegenargument ist, 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.
• Darüber hinaus haben wir ebenfalls festgelegt, dass wir auch Begriffe aus der Sphäre des Domain Driven Design und aus dem technischen Kontext in die Ubiquitous Language aufnehmen möchten.

Fr, 19.10.2018: