Context Map

In der Context Map werden die wichtigsten Geschäftsobjekte und deren Beziehungen dargestellt. Da diese einem Iterativen Prozess unterliegt, werden hier alle Versionen in Chronologischer Reihenfolge und den dazu gehörigen Entscheidungen veranschaulicht.

Version 6

Aus der bestehenden Context Map wurde für die Implementierung ein Domain Model mit Attributen und Beziehungen entwickelt, um festzustellen ob für die verschiedensten Szenarien alle wichtigen Aspekte abgedeckt wurden. Desweiteren kann mit Hilfe des Models sichergestellt werden das Technische Entwickler und Fachliche Entwickler, über den selben Kenntnisstand verfügen.

Abbildung: Domain Model v6

Version 5

Die Entwicklung des Microservice Standortverlauf wird eingestellt und zunächst nicht weiter verfolgt, da er die Persönlichkeitsrechte der DVPs verletzt, ohne dabei einen Mehrwert zu bieten. Als Basis zu dieser Entscheidung diente der Austausch mit den Sozialarbeitern.

Desweiteren wird die Entity Bezugsperson (BP) entfernt, da die Authentifizierung und somit die Authentisierung zum aktuellen Zeitpunkt des Projektes nicht betrachtet wird. Das Value Object Geofence wird aufgelöst und durch die Beziehung zwischen Ort und Lokation implementiert.

Abbildung: Context Map v5

Version 4

Sprachliche Anpassungen

Nach einem Austausch mit Prof. Dr. Bente, hat sich das Team dazu entschieden, bei einzelnen Bezeichnungen Änderungen vorzunehmen, da die Bezeichnungen als unpassend empfunden wurden.

• Umbenennung des Microservices Lokation Historie in Standortverlauf
• Umbenennung des Microservices Route / Ort in Ungewöhnlicher Aufenthaltsort
• Umbenennung des Services Überwachung in Ungewöhnliche Aufenthaltsorte erkennen

Dabei wird hier die der Service ungewöhnliche Aufenthaltsorte erkennen (frühere Bezeichnung: Überwachung) aus Gründen der Anschaulichkeit nicht in einer Modellierten-Version dargestellt.

Abbildung: Context Map v4

Version 3

Bisher hat sich die Gruppe drauf verständigt, dass Orte die mit Kontaktdaten verknüpft sind, als Anlaufstellen betrachtet werden. Dieser Aspekt entfällt in Zukunft aus dem gewonnen Feedback der vorherigen Version.

Folglich wird das Value Objekt Kontaktdaten aus der Context Map der Subdomäne Ungewöhnliche Route draußen entfernt.

Zudem hat sich die Gruppe dazu entschieden, den Microservice Route mit dem Microservice Ort zu verbinden. Da, sonst niemals eine Entscheidung getroffen werden kann, ob eine DVP an einem Ort ist bzw. sich auf einer Route befindet, wo diese nicht sein darf/sollte. Da zum aktuellen Zeitpunkt der Microservice Ort das Gebiet, wo sich die DVP gerade aufhält, als Black markiert, aber der Microservice Route einen Pfad als White markiert. Diese beiden Informationen müssen zusammen ausgewertet werden, um nicht widersprüchliche Aussagen zu tätigen. Dabei bleibt der Microservice zur Historischen Location bestehen, da es hierbei lediglich um eine Auflistung von den Orten/Routen handelt.

Abbildung: Context Map v3

Version 2

Auf Grund der methodischen Kritik im ersten Anlauf, wurde das Vorgehen für den zweiten Anlauf angepasst.

So soll sich die neue Context Map auf die folgenden Building Blocks beschränken und die Beziehung zwischen diesen soll unidirektional dargestellt werden:

• Entity
• Value Object
• Aggregate
• Aggregate Root

Version 2 - Vorgehensweise

Die im ersten Anlauf erstellte Context Map wird als Grundlage verwendet und in ihrer Komplexität reduziert. Hierfür wird auf die Verwendung von Repositories und Services verzichtet.

Stattdessen soll der Fokus jetzt auf die Aggregates bzw. Aggregate Roots gelegt werden, die im Kern aus den im ersten Anlauf definierten Entitys und Value Objects bestehen.

Im Zuge dessen wurden die Repositorys Orte, Routen und Location Historie zu den Aggregate Roots Ort, Route und Historische Location.

Diskussion

Was genau ist ein Aggregate?

• Bei einem Aggregate handelt es sich um eine Zusammenfassung von Objekten (Entitys und Value Objects), die einer starken Bindung unterliegen und somit zusammengehören.
• So kann man nicht ein Element eines Aggregates ändern, ohne die anderen Elemente zu betrachten. Hierbei handelt es sich in der Regel um Fachobjekte, die eng miteinander verbunden sind (z.B.: Ort und Geofence).
• Jedes Aggregate hat ein Aggregate Root, welches den Zugriff auf die Elemente des Aggregates durch andere Elemente außerhalb des Aggregates ermöglicht. Das Aggregate Root definiert hierfür Konsistenzregeln, die eingehalten werden müssen.
• Bei der Implementierung des Modells soll jedes Aggregate als eigenständiges Java-Projekt umgesetzt werden.

Soll auch die Entity Bezugsperson in unsere Context Map aufgenommen werden?

• Primär gehört die Bezugsperson in die Subdomäne Dementiell veränderte Person.
• In der Subdomäne Ungewöhnliche Route draußen wird von der Bezugsperson eigentlich nur der Identifier, also eine ID benötigt.
• Da dies jedoch für die Implementierung einer Zugriffsberechtigung notwendig ist, hat sich die Gruppe dazu entschlossen, die Bezugsperson in die Context Map aufzunehmen. Fachlich betrachtet, darf nur eine der DVP zugeordnete Bezugsperson, Orte, Routen und Locations anlegen, löschen und bearbeiten.
  Muss die DVP und die Bezugsperson innerhalb der Aggregates aufgeführt werden oder sollen diese außerhalb der Aggregates, vielleicht auch außerhalb des Bounded Contexts, auf das Aggregate Root zugreifen?
  • Vorteil: Wenn die beiden Elemente in das Aggregate aufgenommen werden, dann müssen später die anderen Microservices nicht wegen den Daten der Bezugsperson angesprochen werden.
  • Nachteil: Es entstehen redundante Datensätze, die dann in den einzelnen Microservices redundant oder ggf. inkonsistent vorliegen. Dies ließe sich durch eine zentrale Datenhaltung innerhalb eines Microservices verhindern.
  • Entscheidung: Da eine zentralisierte Datenhaltung im Kontext einer Microservice Architektur nicht zwangsläufig erforderlich ist und es der Gruppe wichtig ist, möglichst unabhängig von den anderen Subdomänen agieren zu können, wurde die Entscheidung getroffenn, die DVP und die Bezugsperson in die Aggregates mit aufzunehmen.

Muss in das Aggregate Historische Location der Zeitpunkt als Value Object mit aufgenommen werden?

• Für die bereits in Version eins erläuterten statistischen Operationen, ist der Zeitpunkt wann eine DVP eine Location besucht hat von großer Bedeutung. Folglich konnte sich die Gruppe darauf einigen, den Zeitpunkt als eigenes Value Object mit in das Aggregate Historische Location aufzunehmen.

Ergebnis

Die Gruppe konnte sich auf die einzelnen Fachobjekte und deren grobe Beziehung untereinander einigen. Darüber hinaus wurde festgelegt, um welche Building Blocks es sich bei den einzelnen Fachobjekten handelt. Die Zuordnung erfolgte folgendermaßen:

Aggregate Root

• Ort
• Route
• Historische Location

Value Object

• Kontaktdaten
• Geofence
• Location
• Zeitpunkt

Entity

• DVP
• Bezugsperson

Abbildung: Context Map v2

Feedback:

Prof. Dr. Bente hat angemerkt, dass die Verwaltung von Anlaufstellen eigentlich nicht in der Subdomäne Ungewöhnliche Route draußen liegt. Hierbei handelt es sich um einen Fehler bzw. eine unklar definierte Stelle im Anforderungsdokument.

Version 1

Vorgehensweise

1. Zuerst wurde ein gemeinsames Verständnis über die Aufgabenstellung geschaffen. Im Zuge dessen wurden unklare Begriffe gemeinsam definiert.
2. Anschließend hat jedes Gruppenmitglied seine eigene Context Map erstellt, vorgestellt und erläutert, welche er im Laufe der Woche erstellt hat.
3. Zuletzt wurden die einzelnen Context Maps miteinander verglichen und auf Grundlage dessen wurde eine gemeinsame Context Map erstellt, die sich aus den schlüssigsten Aspekten der individuellen Ausarbeitungen zusammensetzt. Die Auswahl erfolgte dabei demokratisch.

Diskussion

In diesem Abschnitt sind die relevantesten Fragen und Entscheidungen zusammengefasst, die gemeinsam diskutiert wurden.

Welche Entitys bzw. Value Objects benötigen wir im Bezug auf Orte und Routen und wie sollen diese abgebildet werden?

• Im Kern verwenden wir ein Value Object Location. Hierbei könnte es sich technisch um eine GPS Koordinaten handeln. Eine Solche GPS Koordinate würde sich dann aus Längengrad (longitude), Breitengrad (latitude) und Höhe (altitude) zusammensetzen.
• Aus dem Anforderungsdokument geht hervor, dass neben der Entity Ort, eine weitere Entity Route benötigt wird. Da es sich bei Routen um eine Aneinanderreihung von Wegpunkten handelt, haben wir uns dazu entschieden, dass Routen aus einer Mehrzahl von Locations bestehen müssen, die untereinander in einer Reihenfolgebeziehung stehen.
• Die Entity Ort lässt sich grundlegend auch auf das Value Object Location zurückführen. Im Vergleich sind Orte jedoch sowohl fachlich als auch räumlich weiter gefasst. So setzt sich beispielsweise der Ort Stadtpark aus mehreren Locations zusammen. Da es im Kontext der räumlichen Überwachung notwendig ist, die Grenzen von Orten definieren zu können, haben wir uns darauf verständigt, dass es sinnvoll ist, mit Geofences zu arbeiten.
• Ein Value Object Geofence definiert dabei die Grenzen eines Ortes durch mehrere Locations.
• Zusammenfassend lässt sich die Beziehung folgendermaßen beschreiben:

Ort -is composed of-> Geofence -is composed of many-> Location

Für welche Entity sollen Orte, Routen und Locations angelegt, verwaltet und später überwacht werden?

• Für die Entity Demenziell veränderte Person (DVP)

Was beschreibt ein Ort fachlich?

• Ein Ort legt fest, wo sich die DVP i.d.R. befindet, bzw. wo diese sich nicht befindet. (z.B.: Bäckerei, Park)

Soll für die Verwaltung der Whitelist und Blacklist jeweils ein Repository angelegt werden?

• Nein, die Gruppe hat sich mehrheitlich gegen Repositorys für die Blacklist und Whitelist ausgesprochen.
• Stattdessen wird für Ort, Route und Location jeweils ein Repository eingeführt. Ob es sich bei bestimmten Orten, Routen oder Locations um Blacklist-Einträge handelt, soll direkt an einem Attribut der späteren Entitäten bestimmbar sein.
• Blacklist-Einträge definieren dabei Orte, Routen und Locations fachlich als gefährlich.

Wie wird bestimmt, an welchen Orten, Routen und Locations sich eine DVP häufig aufhält?

• Diese Frage soll sich mit Hilfe des Repository Location Historie beantworten lassen. Da es sich bei einem Repository theoretisch um eine filterbare Liste aller Entitäten bzw. Vale Objects eines Typen handelt, soll es möglich sein, diese mit Hilfe von statistischen Operationen abzufragen (z.B.: Ermittle die Summe, wie oft die DVP in den letzten drei Monaten die unterschiedlichen Locations besucht hat und sortiere diese Summen absteigend).
• Hierfür ist es jedoch erforderlich, dass an dem Value Object Location gespeichert wird, wann die DVP diese besucht hat.

Wie modellieren wir die Anlaufstellen? Ist hierfür ggf. auch Repository notwendig?

• Bei einer Anlaufstelle handelt es sich um einen Ort, zu dem Kontaktdaten zu einer dritten Person hinterlegt wurden, die ggf. in einer Notlage, die sich an diesem Ort ereignet hat, helfen könnte. Dies kann beispielsweise die Freundin der DVP sein, die in der Nähe des Stadtparks wohnt.
• Folglich handelt es sich bei einem Ort um eine Anlaufstellen, wenn die Entity Ort mit einem Value Object Kontaktdaten verknüpft ist.
• Da sich die Anlaufstelle aus zwei Building Blocks zusammensetzt, ist für diese kein Repository notwendig.

Gehört neben der Überwachung, die Benachrichtigung bzw. Warnung, beispielsweise wenn etwas nicht in Ordnung ist, ebenfalls in unseren Bounded Context?

• Die Benachrichtigung bzw. Warnung selbst gehört primär in die Subdomäne Behebung einer Notlage.
• Es wäre jedoch denkbar, dass diese Funktionen durch einen Service, der sich in unserem Bounded Context befindet, ausgelöst werden. Dies ist sinnvoll, da die Überwachung bzw. Ortung der DVP durch Services aus unserem Bounded Context bewerkstelligt werden.

Ergebnis

Die Gruppe konnte sich auf die einzelnen Fachobjekte und deren grobe Beziehung untereinander einigen. Darüber hinaus wurde festgelegt, um welche Building Blocks es sich bei den einzelnen Fachobjekten handelt. Die Zuordnung erfolgte folgendermaßen:

Entity

• DVP
• Ort
• Route

Value Object

• Geofence
• Kontaktdaten
• Location

Repository

• Orte
• Routen
• Location Historie

Service

• Überwachung
• Notification/Alert
• Ortung

Abbildung: Context Map v1

Überschneidungen bzw. Überlappungen mit anderen Subdomäne

Ungewöhnliches Verhalten

• DVP (Mittelpunkt, Hauptfugur – für jede Subdomäne von Bedeutung)
• Orte (Wo kann das ungewöhnliche Verhalten auftreten?)
• Ort (zu dem Repository Orte, der Ort)

Demenziell veränderte Person

• DVP (Mittelpunkt, Hauptfugur – für jede Subdomäne von Bedeutung)

Behebung einer Notlage

• DVP (Mittelpunkt, Hauptfugur – für jede Subdomäne von Bedeutung)
• Notification/Altert (Welche BP muss benachrichtig werden, bei einer ungewöhnlichen Situation?)

Draußen-Ortung

• Location (GPS-Koordinate, wichtig für Positionsbestimmung bzw. Standortbestimmung)
• Ortung (Hier Ortung der DVP durchführen)

Probleme

• Gemeinsame Sprache: Jeder hatte ein anderes Verständnis von den Begriffen (z.B.: Wo liegt der Unterschied zwischen einem Ort und einer Anlaufstelle?)

Methodische Kritik

Ist es zu diesem Zeitpunkt bereits sinnvoll Services zu definieren?

• Antwort: In diesem frühen Stadium ist es noch nicht sonderlich sinnvoll. Es soll sich zunächst auf Entitys, Value Objekts und Aggregates konzentriert werden. Zu viel Differenzierung macht das ganze unklarer.
• Antwort: Wir Sprechen noch nicht von Services, sondern einfach nur von Überlappungen mit den anderen BCs. Wenn es um Kommunikation zwischen BCs geht, heißt dies nicht unbedingt, dass eine Überlappung vorliegen muss.