Analyse des fachlichen Szenarios
Das fachliches Szenario zur "ungewöhnlichen Route draußen" wird im folgenden Analysiert. Dabei sollte der Fokus auf der Modellierung möglicher REST APIs liegen. Durch die Einführung der Event-Basierten Kommunikation zwischen den Microservices, benötigt dieses Szenario keinerlei REST APIs.
- Der DDD-Service Ortung meldet entweder regelmäßig den Standort der DVP oder informiert über Standortänderungen.
- Die Kommunikation zwischen dem DDD-Service Ortung und den beiden Microservices Historische Location und Route/Ort erfolgt nicht über eine REST-Schnittstelle.
- Der DDD-Service Ortung fungiert als Message Broker und verschickt Orts-Ereignisse (Events) als Broadcast an alle Microservices.
- Der DDD-Service Ortung liegt dabei nicht in der Subdomäne Ungewöhnliche Route draußen.
- Nach Rücksprache mit dem PO ist die Entscheidung getroffen worden, dass auf die Implementierung einer Blacklist verzichtet wird. Im übertragenen Sinne beginnt jede DVP mit einer "weißen" Karte, doch sobald ein Whitelist Eintrag vorhanden ist, wird die restliche (oder der Hintergrund der) Karte "schwarz".
- Folglich sind Lokationen (seien es Routen, Orte oder GPS-Lokationen) entweder whitelisted, also explizit erlaubt oder sie sind implizit verboten. Sinngemäß gibt es also nur schwarze oder weiße Bereiche. Es gibt also keinen Graubereich, wie zuvor angenommen.
- Wenn der weiße Bereich für einen noch nicht definierten Zeitraum verlassen wird, dann wird ein entsprechendes Ereignis ausgelöst (siehe Punkt 3).
- Entsprechend unserer Modellierung wird ein Ort durch einen Geofence und dieser wiederum durch mehrere Locations repräsentiert. Folglich ist dieser Vorgang überflüssig und wird unter 2.3 mitbehandelt.
- Im Modell werden Routen durch eine Aneinanderreihung von Locations dargestellt.
- Fachlich betrachtet dienen Routen dazu, Orte miteinander zu verbinden. Folglich können auch mehre unterschiedliche Routen zwei Orte miteinander verbinden.
- Hierbei muss auch die ungefähre Abweichung von durchschnittlich 8 Metern berücksichtigt werden. Demnach handelt es sich bei Routen bildlich betrachtet eher um Schläuche als um Linien.
- Eine DVP ist somit nicht auf einer Route (inklusive der noch zu definierenden Toleranz), wenn sie diese für einen definierten Zeitraum verlässt.
- Wie unter 2. beschrieben, sind alle Orte die sich nicht auf der Whitelist befinden, automatisch für die DVPs verboten.
- Aich hierbei muss jedoch die ungefähre Abweichung von durchschnittlich 8 Metern berücksichtigt werden.
- Eine DVP ist somit nicht innerhalb eines Ortes, wenn sie dennoch den Geofence (inklusive der noch zu definierenden Toleranz), der einen Ort repräsentiert, für einen definierten Zeitraum verlässt.
- Wie unter 2. beschrieben, wird auf die Implementierung einer Blacklist verzichtet. Folglich ist dieser Vorgang ebenfalls überflüssig.
3. Vorgang: Wenn eine dieser Bedingungen erfüllt ist, löst das System ein Ereignis „Ungewöhnlicher Ort“ aus.
- Wenn die DVP sich auf keiner erlaubten Route oder an keinem erlaubten Ort befindet, dann wird das Event Ungewöhnlicher Aufenthaltsort als Broadcast versendet.
- Hierfür ist der DDD-Service Ungewöhnlicher Aufenthaltsort erkennen innerhalb des Microservices Ungewöhnlicher Aufenthaltsort verantwortlich, welcher die aktuelle (letzte) Position der DVP mit den Whitelist-Einträgen abgleicht.
- Der DDD-Service Ungewöhnlicher Aufenthaltsort erkennen fungiert dabei auch als Message Broker und empfängt die Orts-Events des DDD-Service Ortung, welche die aktuellen Standortdaten der DVP übermitteln.
- Im Falle eines ungewöhnlichen Aufenthaltsortes eines DVP, versendet der DDD-Service Ungewöhnlicher Aufenthaltsort erkennen das Evens Ungewöhnlicher Aufenthaltsort.
Abbildung: Prozessablauf
-
Zur Vereinfachung des Sachverhaltes hat der PO entschieden, dass wenn das GPS-Signal bzw. die Position verloren geht, keine systemseitige Reaktion erfolgt. Dies wäre beispielsweise der Fall bei einem Ausfall der GPS-Schuhsohle oder wenn die DVP ein Gebäude betreten würde.
-
Wenn die DVP den erlaubten Bereich verlässt, dann muss der DDD-Service Ungewöhnlicher Aufenthaltsort erkennen innerhalb des Microservices Ungewöhnlicher Aufenthaltsort entscheiden, ob er das Event Ungewöhnlicher Ort verschicken muss oder nicht. Da dieses Event jedoch nicht sofort verschickt werden soll, sondern erst wenn sich die DVP für einen definierten Zeitraum außerhalb des erlaubten Bereiches aufhält, muss innerhalb des Microservices Ungewöhnlicher Aufenthaltsort gespeichert werden, wann die DVP den erlaubten Geofence zum ersten Mal verlassen hat:
1. Lösungsalternative: [Outdated]
- Den Microservices Standortverlauf fragen, wann die DVP zum ersten Mal den erlaubten Geofence verlassen hat.
- Problematik: Der Microservices Standortverlauf historisiert die Events des DDD-Services Ortung. Dieser persistiert jedoch nicht, ob die übermittelten Positionsdaten außerhalb des erlaubten Geofence liegen. Diese Logik ist nur im Microservices Ungewöhnlicher Aufenthaltsort vorgesehen.
2. Lösungsalternative:
- Der Microservices Ungewöhnlicher Aufenthaltsort legt ab dem Zeitpunkt des erstmaligen Verlassens des erlaubten Geofence seine eigene Historie an. Dies wäre möglich, da beide Microservices die Orts-Events interpretieren können.
- Problematik: Die so angelegte Historie wäre redundant zu der im Microservice Standortverlauf.
3. Lösungsalternative:
- Der Microservices Ungewöhnlicher Aufenthaltsort persistiert ausschließlich den Zeitpunkt des erstmaligen Verlassens erlaubten Geofence.
- Hierbei handelt es sich um die favorisierte Lösung!
- Der DDD-Service Ortung liegt nicht in unserer Sub-Domäne, sondern in der Sub-Domäne Ortung-Draußen
- 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?