Immohai Architekturentscheidungen¶
Status: informativ
Dokumenttyp: Entscheidungsindex und historische Einordnung
Version: 0.3.0
Stand: 2026-07-05
1. Zweck¶
Dieser Bereich dokumentiert wichtige Architekturentscheidungen und fachliche Grundsatzentscheidungen für Immohai.
ADR steht für:
Architecture Decision Record
Ein ADR hält fest:
Kontext
Entscheidung
Begründung
Konsequenzen
historischen Status
Ziel ist, wichtige Entscheidungen und ihre spätere Ablösung nachvollziehbar zu halten.
2. Gültigkeitsregel¶
ADRs dokumentieren den Entscheidungskontext zum jeweiligen Erstellungszeitpunkt. Sie sind keine parallele fachliche oder technische Wahrheit.
Für den aktuellen Stand gelten in dieser Reihenfolge:
Governance und Quellenzuordnung
führende Architektur- und Fachspezifikationen
maschinenlesbare Verträge und Konfiguration
Implementierung und Tests
historische ADRs als Begründungs- und Kontextnachweis
Eine ältere Detailaussage eines ADR darf eine neuere führende Spezifikation nicht überschreiben. Abgelöste Aussagen werden nicht still gelöscht, sondern in diesem Index und später auch in der jeweiligen Entscheidungsdatei kenntlich gemacht.
Neue Architekturänderungen werden gemäß docs/governance/change-control.md zuerst als einzelnes Architektur-Proposal unter docs/changes/proposals/architecture/ erfasst. Ein angenommenes Proposal wird erst nach vollständiger Integration zur verbindlichen Architektur.
3. Entscheidungsbestand und aktuelle Einordnung¶
| Datei | Titel | historischer Status | aktuelle Einordnung |
|---|---|---|---|
ADR-001-tech-stack.md |
Tech Stack und MVP-Architektur | Angenommen | Grundentscheidung zum statischen MVP weiterhin gültig; konkrete Modulstruktur und Aussagen zu fehlender lokaler Speicherung teilweise überholt |
0001-frontend-mvp-scenario-and-reporting-architecture.md |
Frontend-MVP, Szenario- und Reporting-Architektur | Accepted | wesentliche Detailaussagen durch Modell 0.6.2, Calculation Interfaces und Reporting-Spezifikation abgelöst |
0002-future-private-user-accounts-and-family-workspaces.md |
Spätere private Benutzerkonten und Familien-Workspaces | Deferred | Zielbild weiterhin zurückgestellt; Kontext zu fehlender Objektspeicherung und fehlendem Vergleich teilweise überholt |
0003-future-separate-rent-estimation-page.md |
Spätere getrennte Mietermittlungsseite | Deferred | Trennungsgrundsatz weiterhin gültig; RentEstimate, Dataset-Lifecycle und bewusste Übernahme sind inzwischen teilweise integriert |
0004-future-batch-reporting-and-data-quality.md |
Future Batch Reporting and Data Quality | Accepted | Batch-Zielbild teilweise weiterhin offen; AnalysisDataQualityAssessment ist inzwischen verbindlich und integriert |
0005-future-personal-financing-profile.md |
Späteres personenbezogenes Finanzierungsprofil | Deferred | weiterhin zurückgestelltes Zielbild; keine produktive Implementierung |
0006-future-admin-data-management-and-market-rent-database.md |
Future Admin-Datenmanagement und Marktmietdatenbasis | Accepted | Domänentrennung weiterhin gültig; lokaler Admin- und Marktmietprototyp teilweise integriert, Backend-Persistenz weiterhin offen |
Die Spalte historischer Status übernimmt den Wortlaut der jeweiligen Entscheidungsdatei. Die Spalte aktuelle Einordnung beschreibt nur die heutige Relevanz und ändert den historischen Status nicht.
4. Heute führende Quellen je Konfliktbereich¶
Tech Stack und Deployment¶
docs/specification/architecture/overview.md
docs/specification/architecture/project-structure.md
docs/operations/deployment.md
docker-compose.yml
Frontend, Szenarien und Berechnung¶
docs/calculations/model-specification.md
docs/specification/model-and-calculations/calculation-interfaces.md
docs/specification/user-interface-and-reporting/frontend-mvp.md
Reporting¶
docs/specification/user-interface-and-reporting/reporting.md
docs/specification/user-interface-and-reporting/report-types.md
Datenqualität¶
docs/specification/data-quality-and-validation/data-quality-assessment.md
docs/specification/model-and-calculations/kpi-assessments.md
Meine Objekte und Snapshots¶
docs/specification/product-domains-and-workflows/saved-objects.md
docs/specification/data-quality-and-validation/data-model.md
Marktmiet-Daten und RentEstimate¶
docs/specification/product-domains-and-workflows/market-rent-import.md
docs/specification/product-domains-and-workflows/rent-analysis.md
docs/specification/product-domains-and-workflows/application-domains.md
Batch¶
docs/specification/product-domains-and-workflows/batch-analysis.md
docs/roadmap/roadmap.md
5. Weiterhin gültige Grundentscheidungen¶
Immohai ist eine private App und kein SaaS-Produkt.
Der aktuelle MVP bleibt eine statische Frontend-App.
Rohdaten werden vor der Berechnung normalisiert.
Einzel- und Batch-Vollanalyse verwenden dieselbe Single-Property-Engine.
UI und Reports führen keine eigene Fachlogik ein.
Marktmiet-Datenpflege bleibt von persönlichen Objektanalysen getrennt.
Backend, Benutzerkonten, serverseitige Persistenz und Monte Carlo sind spätere Ausbaustufen.
Die konkrete aktuelle Ausprägung dieser Grundsätze ergibt sich aus den führenden Spezifikationen, nicht aus älteren Modul- oder Feldlisten der ADRs.
6. Bekannte abgelöste Detailaussagen¶
Mindestens folgende historische Aussagen sind nicht mehr als aktueller Stand zu verwenden:
app.js als aktiver Hauptcontroller
ETF-Rendite als Best-/Stress-Szenariovariation
CAPEX ausschließlich als Prozentsatz des Immobilienwerts
Reports lesen gerenderte UI-Werte als primäre Datenquelle
keine lokale Objektspeicherung
kein Objektvergleich
keine aktive Datenqualitätsbewertung
Miete ausschließlich als manuelles Legacy-Feld monthly_rent_market
Admin- und Marktmietbereich nur als noch nicht vorhandene Vorbereitung
Die heute gültigen Regeln stehen in den unter Abschnitt 4 genannten führenden Dokumenten.
7. Entscheidungskriterien¶
Bei Immohai gelten folgende Entscheidungskriterien:
fachlicher Entscheidungsmehrwert
Nachvollziehbarkeit
geringe Komplexität im MVP
testbare Berechnungslogik
klare Trennung von UI und Fachlogik
maschinenlesbare Annahmen
spätere Erweiterbarkeit
keine unnötige Plattformkomplexität
8. Abgrenzung zum Developer Playbook¶
Allgemeine Regeln zur Erstellung von ADRs können im Developer Playbook dokumentiert werden. Immohai dokumentiert hier nur projektbezogene Entscheidungen.
Nicht in diesen Bereich gehören:
allgemeine Git-Regeln
allgemeine Docker-Entscheidungen
allgemeine Nginx-Anleitungen
allgemeine Server-Setup-Entscheidungen
allgemeine Entwicklungsumgebungsentscheidungen
Diese Themen gehören ins Developer Playbook.
9. Pflege des Entscheidungsbestands¶
Bei jeder neuen oder abgelösten Architekturentscheidung sind mindestens zu aktualisieren:
die betroffene Entscheidungsdatei
dieser Entscheidungsindex
Verweise auf Vorgänger und Nachfolger
betroffene führende Architekturdokumente
gegebenenfalls Roadmap, Implementierung und Tests
Eine überholte Entscheidung wird nicht still gelöscht. Ihr historischer Status, die aktuelle Einordnung und die führende Ersatzquelle werden nachvollziehbar dokumentiert.