adr/0003-software-architecture.md

@@ -11,6 +11,8 @@ Draft
 ### Context/Issue
 <!-- Why was this ADR created -->
 
+To not become a big ball of mud over time this devices a clear structure for a structured software over time. TODO
+
 ### Decision
 <!-- What was decided on in the end -->
 
@@ -54,12 +56,24 @@ graph TD
     FRONTEND -->|REST API| SERVICE_SCRAPER
 ```
 
-
 - Frontend [server | GUI]: Hosts the website that the user can interact with
 - Backend [server | REST API]: Hosts the module plan data that the user can change
 - Scraper Service [server | REST API]: Hosts functionality to convert certain files or URLs to structured data
 
-Meaning we have a client that can via an (REST) API layer fetch/post/... all necessary data.
+Meaning we have a client that can via an (REST) API layer (fetch) `get`/`post`/... all necessary data.
+
+The layers keep it flexible to change the database structure or implement new functions without the client needing an update.
+All modules can be developed/tested independently and each module has a clear purpose (separation of concerns). TODO Move to reasoning
+
+---
+
+Concept: Schichtenmodell <-> Entkopplung => Jede Schicht kommuniziert nur mit der direkten Schicht über/unter ihr
+
+---
+
+Inside the modules we use the same concept:
+
+TODO
 
 ## Details
 
@@ -73,6 +87,8 @@ Meaning we have a client that can via an (REST) API layer fetch/post/... all nec
 <!-- What was researched -->
 
 - https://gitlab.mi.hdm-stuttgart.de/se-3/lecture/-/blob/main/website/assignments/Softwarearchitektur.md
+- TODO Separation of concerns
+- TODO Multitier architecture <Schichtenmodell> layers
 
 ### Reasoning
 <!-- What was the reasoning behind the decision -->