3.3 KiB
Table of Contents
- Technologie
- Entwicklung mit Asp.Net (Was ist Blazor? / Was ist Razor? / Kestrel)
- Was ist Oqtane? Architektur von Oqtane?
- Systemarchitektur (Postgres / Oqtane / Nginx )
- Websockets und HTTP 1.1
- Dependency injection
- Projektmanagement
- Learnings
- Probleme mit Oqtane
- Arbeitszeiteinschätzung (Zeitverzug)
- Teamleitung (Motivation / Downsizing)
- Produktion != Staging
- Sprints und Meetings (in Zukunft ja Asyncron
- Modules
Technologie
Entwicklung mit Asp.Net (Was ist Blazor? / Was ist Razor? / Kestrel)
Was ist Oqtane? Architektur von Oqtane?
Systemarchitektur (Postgres / Oqtane / Nginx )
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. 2
- Die Abstraktionen sollen nicht von Implementierungsdetails abhängig sein, sondern die low-level Implementierung sollen gemäß der Abstraktionsschickt implemetiert werden. 2
Ausgangslage ist eine Softwarearchitektur im Direct-Dependency-Graph Model.
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.
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.