ADR-0001 – Landing/App-Domain-Split

Vollständige Fassung mit Mermaid/Ingress-Details: ../architecture/landing-app-domain-split.md. Dieser ADR fasst die Entscheidung im einheitlichen Feature-Doku-Kontext zusammen.

Status

Accepted (2026-06-22), revised to true code/pipeline split (2026-07-09).

Kontext

Marketing-Website und SaaS-App liefen zunächst in einem Next.js-Prozess auf einer Domain. Für klare Trennung von öffentlicher Website und Produkt – inkl. eigenem Scaling und getrennten Secrets – sollten beide getrennt deploybar sein. Primärdomain ist work7.net (ersetzt frühere work7.at-Planung).

Entscheidung

• Zwei Next.js-Apps im Monorepo: src/apps/landing und src/apps/app.
• Zwei Dockerfiles: src/Dockerfile.landing und src/Dockerfile.app.
• Vier Azure-Pipeline-Definitionen: Landing/App je Build + Deploy.
• Landing = Apex (work7.net, Start npm --workspace @work7/landing run start); App = Subdomain (app.work7.net, Start node scripts/start-all.js).
• /auth/signin ist nur noch Legacy-Redirect; die App-Loginseite ist / auf app.work7.net.

Konsequenzen

• ➕ Klare Trennung Marketing/Produkt im Code, in Images und in Releases; Landing-Pod ohne DB/Redis-Secrets; Login unter app.work7.net/.
• ➖ Zwei Builds/Releases pflegen; Provider-Callbacks (DocuSign, WhatsApp, Calendar, Storage) müssen auf die App-Subdomain; NextAuth-Sessions sind host-gebunden.

Alternativen

Ein Runtime-Split über WORK7_SURFACE in einer gemeinsamen Next-App (verworfen); Subpath-Split /app (verworfen zugunsten Subdomain-Branding); getwork7.com (verworfen, zurück auf work7.net).

Verwandte Notes

• 00-architektur-ueberblick · 17-public-website-landing · 20-observability-infra-deployment
• adr-0002-shared-domain-layer