Decision Log

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

18.01.2019

• Wir sind der Meinung, dass sich Microservices für das Hochschulmodul besser eignen.
• Dies ist eine strategische Entscheidung, da kein einzelnes Team entscheiden kann einen Monolithen zu bauen.

11.01.2019

0. Iteration UI

• Wir haben uns für den Einsatz von SPA Components in all unseren Microservices entschieden.

1. Iteration Eventing

• Beim Eventing werden nun die expliziten Objekte verschickt. Es liegt nun am Consumer, diese nach Bedarf aufzulösen.

Sonstiges

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

21.12.2018

• Im Workshop wurde aufgezeigt, dass die Ereignishistorie keinen ausreichend wichtigen Usecase hat, um sie zu behalten.
• Als zu verwendende DB-Technologie haben wir uns für Postgres entschieden. Die Postgres-DBs werden dabei in eigenen Containern deployed.
• Eventing 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.

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 mehr (natürlich trotzdem weiterhin store und update).

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

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, dass die Kalendereinträge verwaltet
• Wir würden die Wahl in der Veranstaltung nochmal zur Diskussion stellen.

Klassifizierung der Subdomäne

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

4. Iteration: Contextmap

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

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

1. Iteration: Spring Boot Implementation

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

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.
• 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

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

0. Iteration: Spring Boot Implementation

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

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 identifizieren können.

26.10.2018

0. Iteration: Context Map

• Aggregat: DVP
• Aggregat: Bezugsperson
• Entity: Hauptverantwortlicher
• Value Object: Einwilligung