decision_log_main - Archi-Lab/fae-team-3 GitHub Wiki

Entscheidungen, die das Eventing betreffen, finden Sie hier.
Verschiedene Versionen des Domain Models finden Sie hier.

Entscheidung Erstellung eines Ablaufdiagramms mit Events für das gegebene Szenario als Diskussionsgrundlage

Ausgangssituation:
Aktuell wird die Funktion der technischen Benachrichtigung als Teil des Microservice BP gesehen. Es ist angedacht, die Funktion ggf. in eigenen eigenen Microservice auszulagern.

Grund:
Es kann sinnvoll sein die Funktion auszulagern, da es als eine technischer Dienst gesehen werden kann und keine Kontaktpunkte mit dem Microservice Bezugsperson vermeidlich vorliegen.

Entscheidung:
Noch keine Entscheidung getroffen.
*Update:
Wird im Rahmen des Projektes nicht mehr umgesetzt.

Ausgangssituation Unklarheiten über die genauen Abläufe und Zuständigkeiten der MS

Entscheidung Erstellung eines Ablaufdiagramms für das gegebene Szenario als Diskussionsgrundlage

Ausgangssituation:
Aus dem fachlichen Kontext geht aktuell nicht hervor ob eine Notlage nur durch eine Bezugsperson bestätigt oder gelöst werden kann.

Grund:
Es kann sinnvoll sein keinen Bezug zu Bezugsperson aufzubauen, da ggf. andere Dinge fähig sind eine Notlage zu lösen.

Entscheidung:
Im aktuellen Kontext sind keine Systeme geplant und es kann sich kein Szenario vorgestellt werden, welches in Zukunft eine Rolle spielen können. Aus diesem Grund wird im ersten Wurf eine Bezugsperson benötigt um eine Notlage zu bestätigen/lösen.
*Update:
Das bedeutet nicht, dass ein Bezugsperson Teil des Notlagen MS ist. Hiermit ist gemeint, dass ausschließlich eine Bezugsperson einen Link auf die API zum Lösen bzw. Bestätigen einer Notlage erhält.

Ausgangssituation:
Im Domain-Model(26.10.18) wurde das Aggregate Benachrichtigung als Root gesehen.

Grund:
Aus unserer Sicht hat die Benachrichtigung keinerlei Identität. Es sollte überlegt werden ob deine Benachrichtigung als Teil einer Notlage gesehen werden soll.

Entscheidung:

Es wurde sich für die Einordnung der Benachrichtigung unter dem Aggregateroot Notlage entschieden.

Ausgangssituation:
Es gibt unterschiedlichste Microservices, die das Erzeugen von Notlagen anstoßen müssen. Die unterschiedlichen Services verfügen über unterschiedliche Gründe, die zum Erzeugen einer Notlage führen. Die Ursachen einer Notlage müssen den jeweiligen Bezugspersonen mitgeteilt werden, sodass eine Bezugsperson eine Notlage auch lösen kann. Ist es sinnvoll die Gründe auszuwerten um der Bezugsperson sinnvolle, strukturierte Detailnformationen mitteilen zu können?

Grund:
Aus unserer Sicht ist eine solche Auswertung nicht gut. Es würde dafür sorgen, dass keine lose Kopplung mehr existiert. Ein erweitern der Domäne um einen neuen Service würde dafür sorgen, dass eine Änderung im Microservice Notlage durchgeführt werden muss.

Entscheidung:
Es wird ein generische Variante im Microservice Notlage verwendet. Der Microservice, der eine Notlage erkannt hat, muss die mitzuteilenden Daten für die Bezugsperson aufbereitet.