Table of contents
Architektur
Version: 2.0.0 Gültigkeit: aktuelle Systemarchitektur Letzter Stand: 4. Juli 2026
Der Bastelhof Homelab Manager folgt einer geschichteten MVVM-Architektur.
Inhalt
App → Services / Data / Connectors / Core
Agent → eigenständiger ASP.NET-Core-Prozess
Services → Core
Data → Core
Connectors → Core
Tests → Core / Services / Data / Connectors
App enthält WinUI-Seiten und ViewModels, Core die Domänenverträge, Data EF Core und Repositories, Services die Anwendungslogik und Connectors die externen Integrationen.
Für den Netzwerk-Scan trennt INetworkScanService CIDR, Begrenzung, Parallelität und Inventarabgleich von INetworkProbe, das ICMP, DNS und Windows-ARP kapselt.
Für das Monitoring erzeugt IMonitoringService eine read-only Momentaufnahme aus Repositories und lokalem Speicherplatz und kapselt die Warnschwellen. Das MonitoringViewModel ergänzt diese Momentaufnahme um normalisierte Zertifikatsdaten des vorhandenen Nginx-Proxy-Manager-Connectors. Die View enthält keine Status- oder Connectorlogik.
Der Installer liegt als Inno-Setup-Skript unter installer/. Die Build-Pipeline veröffentlicht zuerst die selbstenthaltende App und verwendet dieses Verzeichnis anschließend als Setup-Payload. ISCC.exe wird automatisch gefunden. Die Zielpfadseite ist ausdrücklich aktiviert. Programmdateien und Nutzerdaten bleiben getrennt: Setup verwaltet den gewählten Programmordner, die App verwaltet SQLite und Einstellungen im lokalen Benutzerprofil.
ApplicationStoragePathResolver kapselt den Speicherort unabhängig von WinUI. Mit portable.mode wird data/homelab.db relativ zur Anwendung verwendet, ohne Marker bleibt der Standardpfad im Benutzerprofil aktiv. Installer und Portable-Ausgabe basieren auf demselben veröffentlichten App-Payload.
Vor der Paketierung wird dieser Payload auf Kulturordner mit den ISO-Sprachcodes de und en reduziert. Inno-Setup und Portable-Ausgabe werden erst danach erzeugt. Die Sprachprüfung ist Teil der verbindlichen Release-Verifikation.
Das Plugin-System trennt Manifestprüfung, Hash-Vertrauen und Aktivierung über IPluginCatalogService von der Oberfläche. Code wird erst für eine konkrete Aktion in einen entladbaren Assembly-Kontext geladen. IAutomationService führt Regeln aus und schreibt eine Laufhistorie; der Hintergrunddienst arbeitet in kurzen DI-Scopes.
Der separate Linux-Agent bietet ausschließlich einen HTTPS-/Bearer-geschützten Statusendpunkt. IAgentConnector kapselt den Transport. Der Hintergrunddienst aktualisiert aktivierte Agentregistrierungen minütlich, bevor er fällige Regeln auswertet. Agent-Tokens werden über den Windows Credential Manager bezogen.
Hinweise
Geschäftslogik gehört nicht in Views. Implementierungen werden über Dependency Injection gebunden. Projektweite Entscheidungen werden zusätzlich in DECISIONS.md des Hauptrepositories festgehalten.