Decision Log

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

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 ebenfalls engepasst werden.
• Die Fähigkeiten wurden entfernt (Yagni) und das Bewegungsprofil, weil die Funktionalität ein anderer Microservice sinnvoller abbilden kann.
• Ereignisse werden von uns über Events behandelt (DVP greift 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 ersetzt (DELETE + POST), anstatt aktualisiert (PUT) zu werden.
• Die beiden anderen Microservices der DVP Subdomain, AsI und Kalender, erhalten nun eigene REST APIs

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
  • Die AsIs verwalten Kalender und Kalendereinträge, die jeweils eine DVP betreffen
  • Begründung: 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