Decision Log

In diesem Log werden wöchentlich die Gründe für die Architekturentscheidungen, die wir getroffen haben, dokumentiert.

Anmerkung: In den Fällen wo detaillierte Begründungen zu den hier dargelegten Entscheidungen sinnvoll sind, befinden sich diese in anderen Dokumenten, die sich entweder in diesem Wiki, oder einem der Wikis unserer Microservices Assoziierte Instanz, Kalender und Dementiell veränderte Person. Um die Navigation zu erleichtern haben wir an einigen Stellen Direktlinks zu diesen Dokumenten eingefügt.

21.02.2019

7. Iteration: Context Map

• Modellierung aller im Code umgesetzten Value Objects werden zusätzlich dargestellt, um eine vollständige Abbildung der Umsetzung zu haben.
• Das Kalendereintrag Aggregat wurde visuell aus dem Aggregat Kalender ausgelagert. Die Zugehörigkeit zum Kalender Aggregat wird weiterhin durch die unidirektionale Beziehung dargestellt.
• Die Überlappung des Trackers mit der Draußen Ortung wurde entsprechend gekennzeichnet.

01.02.2019

1. Iteration UI

• Um eine Kopplung zwischen den MS zu vermeiden, würden wir eine an DUC und Headful angelehnte Lösung anstreben.
  • Jeder Microservice müsste hierzu eigene UI Fragmente bereitstellen
  • Es soll eine Komposition dieser Elemente stattfinden
  • Ein Template organisiert die Fragmente
  • Ein zusätzlicher Navigations-MS stellt eine UI-Navigation zur Verfügung (Details hierzu würden bei tatsächlicher UI-Umsetzung dann angegangen werden)

3. Iteration: REST API

• Rest weitestgehend reduziert auf Level 2 mit Links auf einzelne Ressourcen
• Hintergrund ist die fehlende Notwendigkeit und der hohe Aufwand bei der Implementierung
• AsI: REST-Schnittstelle soll ermöglichen, eine Verknüpfung zu DVPs herzustellen, um eine Beziehung zwischen DVP und AsI darzustellen.
• Kalender: Es können nicht alle Kalender abgerufen werden. /k gibt eine notfound response zurück. Es muss eine Kalender-Id mit angegeben werden (/k/{k-id}) um einen bestimmten Kalender zu bekommen. Die Alternative ist alle Kalender einer bestimmten DVP zu erhalten (/k?dvpid={dvp-id}).

18.01.2019

Monolith vs Microservices: Fragestellung zum Vortrag (Nockemann)

• Wir sind der Meinung, dass sich Microservices für das Hochschulmodul besser eignen.
• Wir sind der Meinung, dass dies ist eine strategische Entscheidung ist.
• Eine detaillierte Erläuterung unseres Standpunktes findet sich hier.

11.01.2019

0. Iteration UI

• Wir haben uns dafür entschieden, als UI-Paradigma auf SPA (Single Page Application) Components zurückzugreifen. Diese bieten eine Vielfalt von Integrationsmöglichkeiten und eignen sich gut für Frontends mit hoher Interaktivität.
• Die vorgestellten Komponenten sind als ein Vorschlag für ein zukünftiges UI Konzept zu verstehen.

1. Iteration Eventing

• Beim Eventing werden nun die expliziten Objekte verschickt. Es liegt nun am Consumer, diese nach Bedarf aufzulösen.
• Für das Eventing werden nun die durch das REWE-Digital Beispiel gegebenen Producer- und Consumer-Klassen verwendet

Sonstiges

• IDs sind nun UUIDs
• JSON Objekte der Producer sind nun im jeweiligen Repository unter Events einsehbar.

21.12.2018

0. Iteration Containerisierung

• Als zu verwendende DB-Technologie haben wir uns für Postgres entschieden. Die Postgres-DBs werden dabei in eigenen Containern deployed.

0. Iteration Eventing

• Eventing Modellierung beim Microservice Kalender: Wir veröffentlichen den gesamten Kalender einer Person als Topic, nicht nur Ausschnitte aus diesem oder einzelne Kalendereinträge. Wir gehen nämlich davon aus, dass der Kalender selbst in Extremfällen nicht so groß wird, dass das Probleme darstellt.

6. Iteration: Context Map

• Darstellungsanpassung des Kalendereintrag Aggregats zu einer einzelnen Entität innerhalb des Kalender Aggregats. Dies hat den Grund darin, dass der Kalendereintrag von außen nur über den Kalender zugreifbar ist.
• Im Workshop wurde aufgezeigt, dass das Ereignisprotokoll keinen ausreichend wichtigen Usecase hat, um sie zu behalten. Wurde daher aus der Context Map entfernt.
• Ein Tracker Value Object für die Zuordnung von DVPs zu Trackern wurde hinzugefügt.
  • Tracker (überlappt mit Draußen Ortung), wir sehen uns dabei als Customer

Use Cases

• Ereignisprotokoll einsehen entfernt
• Bewegungsprofil einsehen entfernt

07.12.2018

2. Iteration: REST API

• Angepasst auf der Basis der Entscheidung, den Kalender in einem eigenen Microservice zu aggregieren, musste die REST API des Microservice DVP ebenfalls angepasst werden.
• Die Fähigkeiten des Microservice DVP wurden entfernt (Yagni). Außerdem das Bewegungsprofil, weil diese Funktionalität von einem anderen Microservice sinnvoller abgebildet werden kann.
• Ereignisse werden von uns über Events behandelt (DVP greift diese bei Microservice BeN ab), weshalb es hier keinen POST mehr gibt.
• Außerdem wird es keinen PUT auf Bild und Einwilligung geben, da dies Value Objects sind. Diese müssen nur ersetzt (DELETE + POST), anstatt aktualisiert (PUT) zu werden.
• Die beiden anderen Microservices der DVP Subdomain, AsI und Kalender, erhalten nun eigene REST APIs.
• Es gibt keine create oder edit Methoden (gefolgt von "Formular"-Übertragung) mehr (natürlich trotzdem weiterhin store (POST) und update (PUT)).

5. Iteration: Context Map

• Fähigkeiten entfernt (Yagni: You aren't gonna need it)
• Bewegungsprofil entfernt, da durch einen anderen Microservice sinnvoller abgebildet
• Aus der Diskussion während der Veranstalltung:
  • Kalender wird zu einem eigenen Microservice
  • Es wird zwei Aggregate im Kalender Microservice geben. Zum einen mit dem Aggregate Root Kalendereintrag, zum anderen Kalender
  • Jede AsI die einer DVP zugeordnet ist, kann den Kalender dieser zugeordneten DVP verwalten.
  • Eine DVP kann mehrere Kalender haben und ein Kalender kann nur zu einer DVP gehören.
  • Ein Kalender kann mehrere Kalendereinträge haben und ein Kalendereintrag kann nur zu einem Kalender gehören.
  • Zuerst wurde angedacht, dass Kalendereinträge mehreren DVPs und mehreren Kalendern zugeordnet sind. Dieses Konzept erfordert allerdings einen großen Aufwand hinsichtlich der Rechteverwaltung (Welche AsI darf welchen Eintrag bearbeiten? Wie werden DVPs zu Einträgen hinzugefügt, etc.), die unserer Ansicht nach nicht mehr der Idee eines MVPs entspricht.
  • Begründung für den Microservice Kalender: Der Kalender hat mehr Funktionalität, als mit Value Objects und Entities innerhalb eines Aggregates sinnvoll abzubilden ist. Die offensichtliche fachliche Trennung von Kalender und DVP wird hierdurch dargestellt. Außerdem werden die APIs kleiner und übersichtlicher.
• Das Aggregat Kalender:
  • hat Name und Zeitzone als Value Objects
  • Name dient der eindeutigen Benennung des Kalenders, da eine DVP mehrere Kalender haben kann
• Das Aggregat Kalendereintrag:
  • hat Ort, Datum und Titel als Value Objects

30.11.2018

Klassifizierung der Subdomäne

• Entsprechend dem Vortrag Ansgar Brauners sehen wir die Subdomäne Dementiell Veränderter zwischen generic und supportive domain.

4. Iteration: Context Map

• Die Kalendereinträge sind nun nicht mehr ein Ansammlung von value objects der DVP, sondern gehören nun zu einem neuen value object "Kalender"

Kalender

• Problemstellung: Es soll verhindert werden, dass der gesamte Kalender mit all seinen Einträgen verschickt werden muss. Dafür haben wir zwei Lösungen in Betracht gezogen:
  • Eine Projection, die den Kalender beim Zugriff auf die DVP zugänglich macht.
  • Eine eigene Entität für Kalender und Kalendereinträge einpflegen.
• Es wird ein Kalender Value Objekt erstellt, das die Kalendereinträge verwaltet
• Wir würden die Wahl in der Veranstaltung nochmal zur Diskussion stellen.

16.11.2018

Use Cases

• Ereignisprotokoll einsehen hinzugefügt
• Bewegungsprofil einsehen hinzugefügt

Mono- vs Multirepository:

• Entweder alle Microservices in ein Repository (Mono, vgl. Google, Facebook) oder jeder Microservice einzeln in ein eigenes Repository (Multi, vgl. Netflix)
• Domänenweise unüblich --> aktuelle Teamaufteilung nicht wirklich in der Praxis zu finden
• Wenn wir die Teams auseinander halten möchten, bleibt die Multirepository Lösung

1. Iteration: REST API

• Es wurden für alle Value Objects/Entities */edit und */create Ressources angelegt
• {ab-id} wurde aus dem POST request für die Fähigkeiten entfernt. Stattdessen wird via PUT die Fähigkeitenliste aktualisiert. die ab-id der betreffenden Fähigkeit wird dann im HTTP-Body mitgeschickt
• Ein Szenario (Termin für DVP anlegen) wurde als REST mit Hypermedia durchgespielt und dokumentiert

3. Iteration: Context Map

• Der Hauptverantwortliche wird zu einer Rolle im Aggregat der Bezugsperson
• Das Aggregat der Bezugsperson wird für die eindeutige Begrifflichkeit in "Assoziierte Instanz" umbenannt (short 'AsI')
• Es ergeben sich 2 Microservices: DVP und AsI, weil die AsI neben der Verknüpfung zur DVP auch noch Nutzerverwaltungsaufgaben für AsIs hat.
• Wir haben uns gegen die Konzeption und Implementierung eines umfassenden Rollen-Rechte-Systems und zugehöriger Managementfunktionalität entschieden, da dies zum Einen nicht durch unsere Stakeholder gefordert und zum Anderen der Aufwand den Rahmen dieser Veranstaltung gesprengt hätte.
• Positionsdaten wurde in Bewegungsprofil umbenannt. Das ist nach unserem Verständnis konform mit der Definition des Bewegungsprofils im Lastenhefts und hat den Hintergrund, dass wir den Use Case Bewegungsprofil einsehen hinzugefügt haben
• Ereignisprotokoll/-historie wurde in Ereignisprotokoll umbenannt. Das hat den Hintergrund, dass wir den Use Case Ereignisprotokoll einsehen hinzugefügt haben

Sonstiges

• Alle Attribute müssen explizit werden
• POM um angegebene Bibliotheken erweitern

09.11.2018

0. Iteration: REST API

• Alle bisher angedachten Geschäftsprozesse wurden skizziert und als Entwurf in tabellarischer Form dokumentiert.
• Fähigkeiten sind keine Personenbezogenen Objekte (Beispiel: 'In den Bus einsteigen' sollten mehrere Personen können). Deshalb gibt es zwar die Möglichkeit die Zuordnung einer Fähigkeit herzustellen oder zu lösen, aber zur Zeit nicht, die Fähigkeit selber zu erstellen oder zu entfernen.
• Es gibt zwar die Möglichkeit beispielsweise einen Kalender aufzurufen, und Termine anzulegen, allerdings keine, den Kalender selbst anzulegen. Die DVP hat also einen Kalender bei der Erstellung anzulegen (realisiert über @ElementCollections und Listenobjekte). Das gleiche gilt für die Fähigkeitenliste, die Positionsdaten und das Ereignisprotokoll.
• Bei dem Ereignisprotokoll und den Positionsdaten können Einträge nicht nachträglich bearbeitet oder gelöscht werden. Das soll die Integrität der Daten sicherstellen.

2. Iteration: Context Map

• Der Hauptverantwortliche wird als Aggregat und Entity aufgelöst und in noch nicht entschiedener Form in das Aggregat der Bezugsperson integriert.
• Die REST API wurde analog zum RESTbucks Beispiel von Oliver Drotbohm, bzw. spring.io, initial aufgestellt.

02.11.2018

1. Iteration: Context Map

• Einwilligung wurde in das Aggregat der DVP aufgenommen, da sie über die DVP referenziert werden kann und als aggregatloses Value-Object nicht DDD konform ist.
• Hauptverantwortlicher zu Aggregat umformuliert.
• Wir haben keine Services identifiziert.
• Bild wurde dem DVP Aggregat hinzugefügt
  • Bild (überlappt mit Ungewöhnliches Verhalten), wir sehen uns dabei als Supplier oder Confirmist

Sonstiges

• Mithilfe von JPA Notation das Geschäftsmodell abgebildet für DVP, Bezugsperson und Hauptverantwortlichen.
• Dabei fiel auf, dass der Hauptverantwortliche als eigene Instanz nicht sehr sinnvoll ist.

26.10.2018

0. Iteration: Context Map

• Aggregat: DVP
• Aggregat: Bezugsperson
• Entity: Hauptverantwortlicher
• Value Object: Einwilligung
• Mögliche Überlappungen:
  • Bezugsperson (überlappt mit Behebung einer Notlage), wir sehen uns dabei als Supplier oder Confirmist.
  • Positionsdaten (überlappt mit Ungewöhnliche Routen draußen oder “Draußen-Ortung”), wir sehen uns dabei als Seperate Ways oder Confirmist
  • Ereignisprotokoll/-Historie (überlappt mit Behebung einer Notlage oder “Ungewöhnliches Verhalten”), wir sehen und dabei als Seperate Ways oder Confirmist
  • Kalendereintrag (überlappt mit Ungewöhnliche Routen draußen), wir sehen uns dabei als Supplier oder Confirmist
  • Fähigkeiten (überlappt mit Ungewöhnliche Routen draußen, Behebung einer Notlage), wir sehen uns dabei als Supplier oder Confirmist