Skip to content
Snippets Groups Projects
Commit df655ef9 authored by Jonas's avatar Jonas
Browse files

21.01.2024 - add repository adr #33

parent b2f0c543
No related branches found
No related tags found
1 merge request!7Dev in Main Merge
# 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.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment