Entität: Fachlicher Administrator

Der fachliche Administrator ist ein langlebiges Objekt mit eigener Identität

Entität: BP (Bezugsperson)

Die Bezugsperson ist in diesem Kontext ein langlebiges Objekt mit eigener Identität und wechselnden Eigenschaften

Entität: Anfrage

Eine Anfrage muss über einen längeren Zeitraum offen bleiben und kann ihren Status ändern, daher besitzt sie eine eigene Identität

Entität: Kommunikationskanal

Der Kommunikationskanal über den eine Bezugsperson benachrichtigt werden kann, kann sich über die Lebenszeit des Objekts ändern

Entität: DVP (Dementiell Veränderte Person)

Hat im Kontext der Bezugsperson eine eigene Identität

Value Object: Kontaktdaten

Die Kontaktdaten definieren sich über ihre Werte und verfügen nicht über eine eigene Identität, da sie sich nur über ihre Verbindung zur Bezugsperson definieren. Werden sie geändert wird das Objekt durch ein neues Kontaktdatenobjekt mit anderen Werten ersetzt.

Value Object: Priorität

Die Priorität definiert sich ausschließlich über ihre Verbindung zu DVP und BP und verfügt nicht über einge eigene Identität

Value Object: Verfügbarkeit

Verfügt nicht über sich ändernde Eigenschaften, bei neuen Werten wird die Verfügbarkeit ersetzt. Hat eine Identität und ist nur über die Beziehung zur BP definiert

Entität: Notlage

Ein langlebiges Objekt mit eigener Identität. Hat sich ändernde Eigenschaften die die Identität selbst nicht ändern

Value Object: DVP

Wird in unserem Kontext nur lesend genutzt wird und nicht verändert. Lebt nur kurz und in Abhängigkeit von der Notlage.

Value Object: Nachricht

Die Nachricht wird von außen eingegeben und nicht durch das System geändert. Definiert sich nur über ihre Eigenschaften und hat nur Identität in Verbindung mit einer Notlage

1. *MS-*Notlage nimmt eine Nachricht zu einer bestimmten DVP entgegen

2. *MS-*Notlage legt eine Notlage im System an und reichert diese mit weiteren Eigenschaften an

3. *MS-*Notlage sendet eine Benachrichtigung an *MS-*BP

4. *MS-*BP berechnet intern welcher Bezugsperson die Nachricht über welchen Kommunikationskanal zustestellt werden muss und wartet auf eine Antwort.

Dabei wird eine Anfrage angelegt.

(Erfolgt nach Ablauf einer Wartezeit keine Antwort auf die Anfrage sendet *MS-*BP die Nachricht an weitere niedriger priorisierte Bezugspersonen)

5. Wurde die Anfrage bestätigt meldet *MS-*BP dies an *MS-*Notlage

*MS-*Notlage vermerkt die Statusänderung der Notlage

6. Wurde die Anfrage gelöst meldet *MS-*BP dies an *MS-*Notlage

*MS-*Notlage vermerkt die Statusänderung der Notlage

*MS-*BP entfernt die Anfrage

Allgemein sollen die APIs den Prozess unterstützen und keine reinen CRUD Operationen darstellen. Mit den Aufrufen sollen daher, wenn möglich und sinnvoll, Prozesse mit "State Transfer" in Gang gesetzt werden.

URI: /Notlage POST

Externe API um eine Notlage anzulegen und den Prozess der Benachrichtigung einer Bezugsperson anzustoßen. Die API soll es dem aufrufer ermöglichen den weiteren Status der von ihm initierten Notlage zu verfolgen, falls er dies wünscht

URI: /Notlage/{id} POST

Über diesen Aufruf soll der *MS-*BP den *MS-*Notlage über Zustandsänderungen an einer Notlage informieren

URI: /Benachrichtigung POST

Dieser Teil der API soll *MS-*Notlage dazu dienen einen Benachrichtigungsprozess für eine Notlage anzustoßen