Architecture Decision Record · 0018

Sitemap-Strang-zu-Sub-Site-Mapping

TL;DR — Strang 1 + 4 → Corporate (N10), Strang 2 → Projektpartnerportal (N11), Strang 3 → Karriere (N09). Jeder Canvas-Page-Stub bekommt einen description-Tag der Form Sitemap-Knoten N<NN> · Strang <S> · Site: <site-id> · Stub.

Kontext

Der Sitemap-Snapshot docs/context/0002-sitemap.md (Stand 2026-05-03, kanonische Quelle aus dem Miro-Board „Aufbau Website") beschreibt die geplante SOLCOM-IA als vier Stränge unter Home:

Der IT-Landschaft-Snapshot docs/context/0001-it-landscape.md modelliert Drupal 2.0 als zentrales CMS mit drei ausgelieferten Sub-Sites:

Die Sitemap nennt im Abschnitt „Lücken und offene Punkte" die plausibelste Zuordnung (Strang 1+4 → Corporate, Strang 2 → Projektpartnerportal, Strang 3 → Karriere) und markiert sie explizit als „nicht beschriftet — ist sie load-bearing, separat als ADR festhalten". Genau dieser Anchor wird hier eingelöst.

Anlass: Vor dem Anlegen von ~60 canvas_page-Stubs muss klar sein, zu welcher Sub-Site jeder Stub semantisch gehört, damit das Mapping in description getaggt werden kann und eine spätere Multi-Site-Migration ohne Page-für-Page-Diskussion möglich ist.

i
Aktueller Stand der Sub-Site-Realität: nicht durch dieses ADR validiert. Die drei Sub-Sites sind in der IT-Landschaft als Topologie modelliert; ob sie in DDEV / mittwald heute schon als physische sites/<domain>/-Verzeichnisse mit eigenen DB-Instanzen existieren, ist nicht bestätigt. Dieses ADR fixiert das Mapping (Strang → Site), nicht den Switch (Multi-Site-Setup).

Entscheidung

Strang-zu-Sub-Site-Zuordnung wie in der IT-Landschaft als plausibel markiert.

Sitemap-Strang Drupal-Sub-Site (IT-Landschaft)
Strang 1 — Für Unternehmen Corporate (N10)
Strang 2 — Für Freiberufler / Projektportal Projektpartnerportal (N11)
Strang 3 — Karriere bei SOLCOM Karriere (N09)
Strang 4 — Über SOLCOM Corporate (N10)
Globale Knoten (Sprachwechsel, Search, Kontakt, Datenschutz, Impressum) Pro Sub-Site repliziert (Header/Footer)

Konsequenzen für die anstehende Stub-Welle:

Bestätigt durch customer-lens-reviewer (Konsultation am 2026-05-04, Empfehlung Option C aus drei Optionen). Reviewer-Begründung: nur diese Option bestätigt die IT-Landschaft-Topologie, hält das einzige Theme byte_theme unverändert und schiebt keine spätere Migrations-Welle für die ~60 Stubs an.

Rejected alternatives

Option A — Single-Site, alle Stränge auf einer Drupal-Instanz rejected

Alle vier Stränge laufen auf einer einzigen Drupal-Site (z.B. der Default-Site), mit Pfad-Präfixen wie /karriere/..., /projektpartner/.... Verworfen, weil:

  • Widerspricht IT-Landschaft N09/N10/N11 ohne Supersession.
  • Login-Bereich von Strang 2 (Projektpartner-Konsole, N12) lebt im selben Drupal-Container wie öffentliche Corporate-Inhalte — Rollen-/Permission-Trennung müsste künstlich per Module-Logik durchgesetzt werden, statt strukturell per Multisite.
  • Spätere Migration auf die IT-Landschaft-Topologie würde alle ~60 angelegten Stubs (Pfade, Menü-Bindungen, Pathauto-Aliase) erneut anfassen.
Option B — Strang ↔ Sub-Site 1:1 (vier Sub-Sites) rejected

Jeder Strang erhält eine eigene Sub-Site, also Strang 1 als zusätzliche „Für Unternehmen"-Site neben Corporate. Verworfen, weil:

  • Erfindet eine vierte Sub-Site außerhalb der IT-Landschaft N09/N10/N11.
  • Strang 1 und Strang 4 sind beide inhaltlich Corporate-Domain — keine getrennten Brands, kein eigenes Design-System.
  • Maximaler Setup-Overhead (vier Pathauto-Patterns, vier Canvas-Page-Region-Configs, vier Deployment-Targets) ohne dahinterliegendes Konzept.

Consequences

Direkt

Mittelfristig

Open Questions (nicht blockierend für Stub-Anlage)