---
include_toc: true
gitea: none
---

# Technologie
## Entwicklung mit Asp.Net (Was ist Blazor? / Was ist Razor? / Kestrel)
## Was ist Oqtane? Architektur von Oqtane?
## Systemarchitektur (Postgres / Oqtane / Nginx )
```mermaid
architecture-beta
    group server(server)[Server]

    service db(database)[PostgreSQL] in server
    service oqtane(server)[Oqtane] in server
    service nginx(server)[NginX] in server
    
    service internet(cloud)[Internet] 

    internet:R <--> L:nginx
    nginx:R <--> L:oqtane
    oqtane:R <--> L:db
```
## Websockets und HTTP 1.1 


## Dependency injection

### Dependency Inversion Principle [^1]
Das Dependency-Inversion-Principle (DIP / auf Deutsch: Abhängigkeits-Umkehr-Prinzip) ist eines von den 5 `SOLID` Prinzipien in der Softwareentwicklung.

Das DIP unterscheidet zwischen high-level und low-level Modulen.
- Die high-level Module beschreiben die Applikations- / Buisnesslogik, ohne direkt mit den low-level Modulen zu interagieren, sondern lediglich auf abstraktionen. [^3]
- Die Abstraktionen sollen nicht von Implementierungsdetails abhängig sein, sondern die low-level Implementierung sollen gemäß der Abstraktionsschickt implemetiert werden. [^3]

Ausgangslage ist eine Softwarearchitektur im Direct-Dependency-Graph Model.

```mermaid
architecture-beta
    service a(mdi:package-variant-closed)[Klasse A] 
    service b(mdi:package-variant-closed)[Klasse B]
    service c(mdi:package-variant-closed)[Klasse C]

    a:R --> L:b
    b:R --> L:c
```
Bei diesem Beispiel ist die Klasse A ein high-level Modul, welches direkt auf die Klasse B referenziert, was das DI-Prinzip verbietet.
Das Problem dabei: Die einzelnen Klassen sind eng gekoppelt, was das austauschen von B mit einer anderen Klasse unmöglich macht. Genau dieses Problem wird vom DIP gelöst.

```mermaid
architecture-beta
    service a(mdi:package-variant-closed)[Klasse A] 
    service b(mdi:package-variant-closed)[Klasse B]
    service ib(mdi:car-clutch)[Interface B]
    service c(mdi:package-variant-closed)[Klasse C]
    service ic(mdi:car-clutch)[Interface C]

    a:B --> T:ib
    ib:R <-- L:b
    b:B --> T:ic
    ic:R <-- L:c
```
Das high-level Modul ruft lediglich eine Abstraktion eines low-level Moduls auf, welche ein von einem, oder mehreren low-level Modulen implementiert worden ist. Für das high-level Modul ist es hier egal, welches low-level Modul die Implementierung bereitstellt. Dadurch erhält man einen viel modulareren Aufbau in der Software. Die einzelnen Module sind auch leichter austauschbar, testbar. Genau diese Modularität macht dependency injection möglich.

### Microsoft Dependency Injection Framework


[^1]: https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/architectural-principles#dependency-inversion

[^2]: https://blog.logrocket.com/dependency-inversion-principle/

[^3]: https://www.oodesign.com/dependency-inversion-principle

[^5]: https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection/overview
# Projektmanagement
## Scrum
## YouTrack
## Gitea (mit Issues)
## Git
## Kommunikation

# Learnings
## Probleme mit Oqtane
## Arbeitszeiteinschätzung (Zeitverzug)
## Teamleitung (Motivation / Downsizing)
## Produktion != Staging
## Sprints und Meetings (in Zukunft ja Asyncron

# Modules
## Mass Mailer
## Event Registration
## Schwarzes Brett