Offene Fragen vor Entwicklungsbeginn

Stand: 15. Mai 2026 Reviewer: Claude Bezug: Hosting-Backoffice v0.1 (vollständiger Basisbestand)

Diese Fragen müssen vor Beginn der V1-Implementierung beantwortet sein. Sie sind nach Themenbereich gruppiert. Innerhalb jedes Bereichs sind sie nach Dringlichkeit geordnet.

1. Mandantenfähigkeit

Welches Tenancy-Modell gilt für V1: Shared Database mit tenant_id-Scope, Schema-pro-Tenant, oder Database-pro-Tenant?
Was bedeutet organisation_id zusätzlich zu tenant_id? Sind beide Synonyme (eines streichen) oder Hierarchieebenen (dann mit ER-Modell zeigen)?
Wie wird Tenant-Isolation technisch erzwungen? Eloquent Global Scope, Policy-Layer, Row-Level Security in Postgres, Connection-Switching, oder Kombination?
Wie viele Subjektebenen hat das Berechtigungsmodell? Plattformbetreiber → Mandant → Endkunde, oder mit Reseller-Zwischenebene?
Wie sieht der Tenant-Lifecycle aus: Provisioning, Suspend, Termination, Datenexport, Offboarding?
Wie wird Cross-Tenant-Datenzugriff für Plattform-Admins technisch geregelt (Impersonation, Read-only-Bypass, Audit-Pflicht)?
Wie wird beim Wechsel von V1 (Single-Tenant) zu V2/V3 (Multi-Tenant) der erste Mandant migriert?
Gibt es Cross-Tenant-Ressourcen (gemeinsame Templates, Knowledge Base, Module Registry), und wie sind sie modelliert?

2. Datenmodell

Wie sieht das vollständige ER-Modell mit Beziehungen und Kardinalitäten aus?
Welche Statusmaschinen existieren für Vertrag, Domain, Hostingpaket, Ticket, Rechnung, und welche Übergänge sind erlaubt?
Wie werden Nummernkreise pro Mandant verwaltet (lückenlos, GoBD-konform, separat für Kunde/Vertrag/Rechnung)?
Wird Kunde in Party/Address/ContactPoint aufgespalten, oder als monolithisches Objekt gehalten?
Wie wird B2B vs. B2C unterschieden im Datenmodell?
Wie wird das Spannungsfeld Soft-Delete / GoBD-Retention / DSGVO-Löschung technisch aufgelöst? Tombstone-Modell mit Pseudonymisierung?
Wie werden externe Referenzen modelliert (generisches Pattern statt anbieter-spezifischer Felder im Core)?
Wie ist das Audit-Log-Schema, und wie wird Unveränderbarkeit garantiert (Hash-Chain, Append-only-DB, externes Sink)?
Werden Verträge versioniert (Vertragsversion, Änderungshistorie)?
Wie werden Subscriptions/Laufzeiten modelliert (Vertrag.Laufzeit reicht nicht für Up-/Downgrade und Pro-rata)?
Wie wird die Many-to-many-Beziehung Vertrag↔Produkt, Vertrag↔Domain, Vertrag↔Hostingpaket modelliert?
Wie ist das Asset-/Dokument-Modell (Hashes, Content-Addressing, Versionen, Storage-Backend-Abstraktion)?

3. API

Welcher Auth-Stack: Sanctum Personal Access Tokens, Sanctum SPA-Mode, Passport/OAuth2, oder Kombination je Client-Typ?
Gibt es OpenAPI 3.x als verbindliche Spec, und ist die Implementierung spec-first?
Welches Error-Modell wird verwendet (Problem Details RFC 7807 empfohlen)?
Welche Pagination-Strategie: Offset, Cursor, Page?
Welche Idempotenz-Strategie für nicht-idempotente Operationen (Domain-Registrierung, Rechnungsanlage)?
Wie sieht das Filtering-/Sorting-Schema aus?
Wie wird API-Versionierung über /api/v1/ hinaus gehandhabt (Deprecation, Sunset, Compatibility)?
Gibt es Webhooks/Outbound Events? Welches Format, welche Signaturen, welche Delivery-Garantien?
Wie werden Rate-Limits pro Mandant skaliert (nicht nur pro IP/Token)?
Welche Endpoints sind read-only, welche schreibend, und wie ist das in der Auth-Scope-Logik abgebildet?
Wie werden Long-Running-Operations modelliert (Domain-Imports, große Synchronisationen) – synchron, asynchron mit Job-Status-Endpoint, oder via Webhook-Callback?

4. Core- und Modulgrenzen

Was gehört verbindlich in den Core, was in Service-Module, was in Integrationsmodule? (Aktuelle Liste in module-structure-v0.1.md ist unvollständig.)
Wo lebt Billing architektonisch? Im Core (Daten heute dort), als Service-Modul, als Adapter-Verbund?
Wo lebt das Customer Portal? Service-Modul oder eigenes UI-Modul?
Wie ist ein Modul technisch verpackt – Composer-Package, in-app Namespace, Nwidart-Modul, anderes?
Wie kommunizieren Module untereinander: Events, Service-Contracts, beides?
Wie wird die Modul↔Core-API versioniert? Wie deklariert ein Modul seine Core-API-Mindestversion?
Was passiert bei Modul-Deinstallation mit existierenden Datenreferenzen?
Wie sind Modul-Migrationen mit Core-Migrationen verzahnt?
Wer ist „Owner" jeder Entität (Aggregate Root)? Insbesondere: Wer besitzt Rechnung – Billing-Modul oder Core?
Wie wird ein generisches External-Reference-Pattern eingeführt, ohne die heutigen anbieter-spezifischen Felder zu zementieren?

5. Sicherheit und Compliance

Wie werden Registrar-/Provider-API-Credentials gespeichert? Externer Vault, eigenes Verschlüsselungsschema, KMS, HSM?
Wer ist GoBD-Verantwortlicher für Rechnungen – Hosting-Backoffice oder das externe Billing-System (Lexware/Invoice Ninja)?
Falls Hosting-Backoffice GoBD-Verantwortlicher ist: Welcher Mechanismus garantiert Unveränderbarkeit nach Festschreibung?
Wie wird DSGVO-Auskunft pro Endkunde umgesetzt (vollständiger Datenexport in maschinenlesbarer Form)?
Wie wird DSGVO-Löschung pro Endkunde umgesetzt, ohne GoBD-Retention zu verletzen (Pseudonymisierung)?
Wer ist Auftragsverarbeiter zwischen Plattformbetreiber und Mandant (DPA)? Wie ist die Beziehung Mandant↔Endkunde geregelt?
Welche Subprozessoren werden eingesetzt (insbesondere KI-Provider, Mail-Versand, Hosting-Region, Backup-Region)?
Wo werden Audit-Logs gespeichert, und wie wird ihre Integrität garantiert?
Welche Authentication-Faktoren werden unterstützt (Password, 2FA, WebAuthn)? Pflicht für Admins?
Welche Session-Strategie (Lifetime, Idle-Timeout, Refresh, Revocation)?
Wie wird Datenresidenz garantiert („europäisch" auf welcher Ebene: Hosting, DB, Backup, Subprozessoren)?
Wer haftet bei kompromittierten Registrar-Credentials? Welche technischen Maßnahmen reduzieren das Risiko?
Welche AGB-/Widerrufs-Mechanismen werden bei Customer Portal benötigt?
Ist BFSG/Barrierefreiheit für das Customer Portal relevant (EU-Verordnung seit 28.06.2025)?

6. Integrationen

Wie ist der formale Adapter-Contract definiert (Interface-Methoden, Fehler-Schema, Auth, Idempotenz)?
Wie werden Adapter-Fehler behandelt (Retry, Backoff, Circuit Breaker, Dead Letter)?
Wie wird inkonsistenter Zustand zwischen Core und externem System aufgelöst (Reconciliation, manueller Eingriff)?
Wie werden Adapter-Konfigurationen pro Mandant verwaltet (Mandant A nutzt Lexware, Mandant B Invoice Ninja)?
Was ist die Bedeutung von „Zahlungsart PayPal/Wero": reine Statusanzeige oder echte Integration?
Wie wird SEPA-Lastschrift modelliert (Mandate, UMR, Pre-Notification, IBAN-Verschlüsselung)?
Welche Steuer-/MwSt-Logik liegt im System, welche im Billing-Adapter?
Was passiert bei Modul-Updates eines Adapters mit nicht-rückwärtskompatiblen Änderungen?
Wie wird Mail-Versand (SMTP/Transactional) als eigene Integration gehandhabt? Welcher Anbieter? SPF/DKIM/DMARC-Strategie?

7. WordPress-Plugin

Welche Auth-Brücke zwischen WordPress und Hosting-Backoffice? OAuth2 Client Credentials? App-Token pro Mandant? Endkunden-Delegation?
Speichert das Plugin Daten lokal in WordPress (Sync-Risiko) oder ist es reiner API-Konsument?
Wie wird WP-User-Identität auf Backoffice-User-Identität gemappt?
Wie ist das Plugin-Update-Lifecycle (eigener Auto-Updater, WordPress.org-Repository, privates Repo)?
Welche API-Scopes erhält das Plugin? Was passiert bei kompromittierter WP-Site?
Wer ist Mandant aus Sicht der API, wenn ein WP-User klickt – der WP-Site-Betreiber oder der endgültige Endkunde?
Welche Caching-/Stale-Data-Strategie hat das Plugin gegenüber der API?

8. KI-Assistent

Bleibt KI in V1 oder rückt es in V2 (Empfehlung: V2)?
Welcher KI-Provider? OpenAI, Anthropic, Mistral, lokal?
Wenn US-basierter Provider: DPA, SCC, Drittlandtransfer-Risikobewertung?
Welche Daten gehen an die KI – Inhalte oder nur Metadaten? Auf welcher Datenklassifikation basiert das?
Wie wird Endkunden-Zustimmung eingeholt, falls Support-Tickets KI-verarbeitet werden?
Wie werden Halluzinationen kontrolliert (Mensch-im-Loop, Confidence-Schwellen, Quellen-Citation)?
Wer haftet bei falschen KI-Vorschlägen (insbesondere bei Rechnungs-/Vertragsdaten)?
Wie wird KI-Output protokolliert und auditiert?

9. V1-Scope

Endgültige V1-Kundenzahl: 1–50 oder 1–500? (Empfehlung: 1–50, Roadmap-Wert)
Kundenportal in V1 oder V2? (Empfehlung: V2)
KI-Assistent in V1 oder V2? (Empfehlung: V2)
SEPA-Lastschrift in V1 oder V2? (Empfehlung: V2 oder vollständiges Modell jetzt)
PayPal/Wero in V1: reine Anzeige oder Integration?
Welche Mahnwesen-Funktionalität ist V1-Minimum (Status „überfällig" + manuelle Mail)?
Welche Tax-/MwSt-Funktionalität ist V1-Minimum?
Welche DSGVO-Funktionen sind V1-Pflicht (Auskunft, Löschung, Datenportabilität)?
Welche Backup-/Restore-Funktion ist V1-Pflicht?

10. Deployment und Operations

Self-hosted-only oder SaaS-Variante geplant? Welcher Mix?
Welche PHP-Version? Welche Laravel-Version?
Welcher Queue-Driver in V1 (Database, Redis)?
Welche Backup-Strategie pro Mandant?
Welche Disaster-Recovery-Strategie?
Welche Logging-/Monitoring-Tools (Sentry, Loki, Grafana, Telemetry-Provider)?
Welcher CI/CD-Stack?
Welche Update-/Migration-Strategie auf Kundensystemen (bei Self-hosted)?
Welche Update-Strategie für Module unabhängig vom Core?

11. Lizenz und Geschäftsmodell

Welche Open-Source-Lizenz, oder Closed-Source?
Welche kommerzielle Lizenz für Mandanten?
Werden Module einzeln verkauft, oder als Bundle?
Wer darf Module von Drittanbietern entwickeln und verteilen?
Wie wird das Versprechen „europäisch" geschäftlich umgesetzt (Hosting-Region, Subprozessoren, Vertragsrecht)?

Diese Liste ist nicht vollständig, aber priorisiert. Die Punkte unter 1, 2, 4 und 5 sind harte Blocker für Codebeginn. Die übrigen können in v0.2 oder begleitend zur ersten Implementierungsphase entschieden werden.

10 KiB Raw Blame History Unescape Escape