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

- dementiell veränderte Person
- ungewöhnliche Route draußen
- Ungewöhnliches Verhalten
Fachlicher Administrator (FA)
Die Subdomäne bildet sich aus der Root-Entity "Fachlicher Administrator". Unter diesem liegen keine weiteren Entities und Value Objects.
Services:
- Fachlichen Administrator abgleichen (-> eventuell von anderer Domäne): Hier werden die notwendigen Daten eines fachlichen Administrators aus der ext. Domäne "dementiell veränderte Person" geholt
Notlage
Die Subdomäne bildet sich aus der Root-Entity "Notlage". Hierin wird die Notlage einer DVP erzeugt, behandelt und gelöst. Diese hat einige Attribute und 3 Value Objects:
- DVP: Die DVP, die sich in einer Notlage befindet
- Status: Der Status einer Notlage kann die Werte "Offen", "Angenommen" und "Gelöst" annehmen
- Nachricht: Die Nachricht, die an die zuständigen BPs gesendet wird und die nähere Details zu der Notlage enthält. Wie die Nachricht genau aussieht, entscheidet diese Domäne nicht
Services:
- Notlage annehmen: Von den Domänen "Ungewöhnliche Route draußen" und "Ungewöhnliches Verhalten" können auf irgendeine Art und Weise Notlagen an die Subdomäne "Notlage" weitergereicht werden, welche von dieser gespeichert werden
- Nachricht bestätigen: Die Subdomäne BP kann eine Notlage bestätigen, wenn sich eine reale BP um die Notlage kümmert
- Nachricht lösen: Die Subdomäne BP kann eine Notlage, wenn eine reale BP die Notlage gelöst hat
BP (Bezugsperson)
Die Subdomäne bildet sich aus der Root-Entity "BP". Hierin werden alle notwendigen Informationen zu einer BP gespeichert, dazu gehören die Entities:
- Kommunikationskanal: Hier werden alle Wege gespeichert, über die eine bestimmte BP erreicht werden kann
- Benachrichtigung: Die Benachrichtigung, mittels der eine BP über eine Notlage informiert wird
- DVP: Eine BP kann für mehrere DVPs zuständig sein, gleichzeitig kann eine DVP mehrere zuständige BPs haben. Dazu ist einer BP zugeordnet, für welche DVPs sie zuständig ist, und mit welcher Priorität (Value Object) diese über eine Notlage benachrichtigt werden sollen
Weitere Value Objects:
- Verfügbarkeit: Hier wird gespeichert, wann eine BP erreichbar ist, und wann nicht
Services:
- BP abgleichen: Dieser Service holt von der externen Domäne "dementiell veränderte Person" alle notwendigen Informationen, die für die Subdomäne "BP" notwendig sind
- Vertrauenswürdigkeit prüfen: Die Subdomäne "Fachlicher Administrator" kann mittels dieses Services alle Informationen von "BP" abfragen, die er benötigt, um die Vertrauenswürdigkeit einer BP zu ermitteln
- Benachrichtigung versenden: Die Subdomäne "Notlage" kann hier nach dem Erzeugen einer Notlage die Subdomäne "BP" darüber informieren, dass zu einer bestimmten Notlage die dazugehörigen BPs informiert werden sollen
Version 0

Vorgehen:
Erste Idee einer Context Map für die Entitys, Objects und Attributes.
Version 1

Vorgehen:
Erster Versuch die Subdomäne aufzuspalten, kompletter Neuentwurf.
Value Objects und Entities, Aggregates identifiziert und Roots spezifiziert.
Im ersten Schritt sollte jeder Aggregate-Root einem Microservice entsprechen.
Services(DDD) wurden nicht berücksichtigt.
Version 2

Vorgehen:
Erster Versuch Services in das Modell zu integrieren.
Modell um Repositories erweitert.
Überarbeitung des Domänenschnitts. Benachrichtigung wird Teil der Notlage, da ein Value Object kein Root sein kann. Benachrichtigung ist Teil einer Notlage.
Version 3

Vorgehen:
Bounded Contexte festgelegt.
Services zu Contexten zugeordnet und als API interpretiert(da Aussage vom "Rest beyond the obvious"-Vortrag).
Benachrichtigung umformuliert in Anfrage und in BP verschoben, da sich eine Anfrage immer an eine BP richtet.
"BP abgleichen" und "Fachlicher Admin abgleichen" als Service(DDD) hinzugefügt, da Informationen außerhalb unserer Domäne liegen. "Notlage annehmen (von außen)" als Service hinzugefügt, da andere Domänen die Gegebenheit für eine Notlage erzeugen.
DVP Entity unter BP hinzugefügt, da BPs und DVPs einander zugeordnet werden müssen.
Kleinere Anpassungen an Value Objects und Entities vorgenommen.
Version 4
Vorgehen:
Externe Domänen in Modell eingefügt.
Services werden nicht mehr als API verstanden.
Services spiegeln Aktionsfluss wider und nicht API-Calls oder Events.
Notlage um Status erweitert, siehe Zustandsdiagramm.