21.01.2024 - add repository adr #33

Documentation/ADR (architecture decision record)/repository-adr.md

+# Architecture Decision Record
+### Titel: Repository Entscheidung
+### Datum: 21.01.2024
+### Status: Accepted
+
+## Kontext: 
+Die Datenstruktur der Models in unserem Projekt ist folgendermaßen aufgebaut: 
+Es gibt ein Tournament Model, was die anderen Models beinhaltet. Das Tournament Model beinhaltet beispielsweise eine Map der UUIDs und Team Objekte der Teams,
+welche am Tournament teilnehmen. Aufgrund der verschiedenen Models hatten wir nun zwei Möglichkeiten die Daten in der Datenbank zu speichern. Die erste Möglichkeit bestand darin, für jedes Model ein eigenes Document mit eigenem Repository Interface zu erstellen. Die zweite Möglichkeit war, 
+das Tournament Objekt zu speichern und sämtliche Datenänderungen am Tournament Objekt vorzunehmen. 
+
+## Entscheidung: 
+Aufgrund dessen, das wir uns für das NoSQL Datenbank Framework MongoDB entschieden haben, hielten wir es für sinnvoll, den objektorientieren Datenpersistierungsansatz zu verfolgen. Daher haben wir uns dazu entschlossen nur das Tournament Objekt zu speichern und alle Daten in diesem Objekt zu speichern. 
+Ein weiterer Grund für diese Entscheidung war, dass wir nur das Tournament Objekt zum Updaten des Frontends an das Frontend senden. Somit wären weitere Endpoints überflüssig gewesen. Zudem hätten weitere Documents in der Datenbank dazu geführt, dass wir im Tournament Objekt nur die Pointer auf die Objekte (z.B. Team) speichern können. Andernfalls hätten wir die 
+Objekte doppelt, also einmal am Tournament und einmal im seperaten Document gespeichert. Um dies zu verhindern hätten wir einen Mapper schreiben müssen, der die UUIDs durch die Objekte ersetzt, bevor wir das Tournament Objekt ans Frontend hätten senden können, was noch einmal mehr Aufwand gewesen wäre. 
+
+## Berücksichtigte Alternativen
+Eine Alternative zur objektorientieren Datenpersistierung der MongoDB wäre eine relationale MySQL Datenbank gewesen. Allerdings hatten wir uns schon früh im Objekt für die MongoDB entschieden, da wir bisher auch nur wenig Erfahrungen mit diesem Framework sammeln konnten und den objektorientieren Ansatz ausprobieren wollten. 
+