ADR - RobinNunkesser/isdcompanion-concept GitHub Wiki

Entwurfsentscheidungen

ADR01 Verzicht auf eigenes Backend

Kontext

Es ist möglich die App mit oder ohne eigenes Backend umzusetzen.

Entscheidungsbeschreibung

In der ersten Version der App wird auf ein eigenes Backend verzichtet.

Konsequenzen

Ein Verzicht auf ein eigenes Backend bedeutet, dass nur die Daten dynamisch geladen werden können, die bereits in externen Backends bereit stehen. Für andere Datenaktualisierungen ist ein Update der App nötig.

Status

Akzeptiert

ADR02 Nutzung der Hexagonalen Architektur

Kontext

Das Projekt soll in möglichst sauberer Arbeitsteilung umgesetzt werden. Perspektivisch können verschiedene Backendtechnologien in verschiedenen Umgebungen zum Einsatz kommen.

Entscheidungsbeschreibung

Als Makroarchitektur des Projekts wird die Hexagonale Architektur eingesetzt.

Konsequenzen

Die saubere Entkopplung über Ports und Adapter erleichtert die Zusammenarbeit.

Status

Akzeptiert

ADR03 Essensfilter in Einstellungen

Kontext

Das Essensangebot der Mensa muss an sinnvoller Stelle nach Allergenen und Zusatzstoffen gefiltert werden können.

Entscheidungsbeschreibung

Die Filter für Mensagerichte werden in den Einstellungen vorgenommen. Im Normalfall sind Allergien und der Wunsch nach dem Ausschluss von Zusatzstoffen dauerhafte Filter. Daher sind sie in den Einstellungen am besten aufgehoben.

Konsequenzen

Auch bei jedem Neustart der App sind die Filtereinstellungen aktiv.

Status

Akzeptiert

ADR04 Stundenpläne nach Semester

Kontext

Über die App lassen sich Stundenpläne für das Studium einsehen.

Entscheidungsbeschreibung

Es wird jeweils der Stundenplan für das in den Einstellungen gewählte Semester angezeigt.

Konsequenzen

Studierende, die nicht mehr im „Plan” sind, müssen ggfs. häufiger in den Einstellungen das Semester wechseln.

Status

Akzeptiert