Vorlage für Unternehmenswebsite - Systemarchitektur-Prompt

## 1. Projektpositionierung Dieses Template-System ist eine wiederverwendbare, modulare Website-Architektur für Unternehmenswebsites. Es löst das Problem, dass jedes Unternehmen eine eigene Website von Grund auf neu entwickelt, was zu hohen Kosten, langen Entwicklungszeiten und inkonsistenter Qualität führt. Das System eignet sich für Technologieunternehmen, Einzelhandel, Dienstleistungsbetriebe, Web3/Blockchain-Projekte, SaaS-Unternehmen und Markenpräsentationen. Es eignet sich nicht für hochspezialisierte Plattformen mit komplexen individuellen Geschäftslogiken, die über Standard-Unternehmenswebsites hinausgehen. Der Kernwert liegt in der Trennung von fixem Skelett und konfigurierbaren Teilen. Das Skelett - Seitenstruktur, Komponenten, API-Muster, Datenmodelle - bleibt stabil. Die konfigurierbaren Teile - Marke, Inhalte, Module, Stile - werden über Konfigurationsmechanismen ausgetauscht. Dies ist effizienter als Einzelentwicklung, weil die Architektur, die Komponentenbibliothek, die Backend-Struktur und die Konfigurationsmechanismen nur einmal gebaut werden. Jede neue Website wird zur Konfigurationsübung statt zur Neuentwicklung. ## 2. Bekannte Informationen und Annahmen ### Bekannte Informationen - Es soll ein wiederverwendbares Enterprise-Website-Template-System entstehen - Das System soll für verschiedene Unternehmenstypen einsetzbar sein: Technologie, Einzelhandel, Dienstleistung, Web3/Blockchain, SaaS, Markenpräsentation - Es muss eine einheitliche Struktur, austauschbare Markenelemente, erweiterbare Funktionsmodule und langfristige Wartbarkeit bieten - Frontend und Backend müssen abgedeckt sein ### Annahmen - **Annahme**: Das System wird als Multi-Tenant-Architektur aufgebaut, bei der jede Unternehmenswebsite eine eigene Instanz mit eigener Konfiguration ist - **Annahme**: Die Zielunternehmen haben Standard-Anforderungen an Unternehmenswebsites: Startseite, Über uns, Produkte/Dienstleistungen, Kontakt, Blog, FAQ - **Annahme**: Die technische Basis ist modern und cloud-fähig, aber nicht auf ein bestimmtes Hosting-Unternehmen festgelegt - **Annahme**: Die erste Version wird für ein Technologieunternehmen gebaut, um die Architektur zu validieren - **Annahme**: Das Team, das das System wartet, hat Kenntnisse in modernem JavaScript und gängigen Backend-Sprachen ## 3. Designprinzipien des Template-Systems **Einheitliches Strukturprinzip**: Alle Websites im System teilen dieselbe Seitenhierarchie, Komponentenbibliothek und Datenmodelle. Dies reduziert kognitive Last für Entwickler und ermöglicht schnelle Fehlerbehebung über alle Instanzen hinweg. **Konfigurierbarkeitsprinzip**: Jede sichtbare Eigenschaft - Logo, Farben, Schriftarten, Texte, Modulreihenfolge - ist konfigurierbar. Dies ermöglicht Markenanpassung ohne Codeänderung. **Erweiterbarkeitsprinzip**: Neue Module und Seiten können hinzugefügt werden, ohne bestehende Strukturen zu brechen. Die Architektur erlaubt Plugin-artige Erweiterungen. **Markenentkopplungsprinzip**: Das System kennt keine spezifische Marke. Markenidentität wird als Konfiguration behandelt, nicht als Code. Dies verhindert, dass eine Marke die Architektur verzerrt. **Frontend-Backend-Trennungsprinzip**: Frontend und Backend kommunizieren ausschließlich über definierte APIs. Dies ermöglicht unabhängige Skalierung, getrennte Deployment-Zyklen und parallele Entwicklung. **Wartungskosten-Kontrollprinzip**: Jede Entscheidung wird darauf geprüft, ob sie die Wartung über viele Instanzen hinweg vereinfacht oder erschwert. Komplexität wird nur akzeptiert, wenn sie direkten Nutzen bringt. **Konsistentes User-Experience-Prinzip**: Trotz unterschiedlicher Marken bleibt die Interaktionslogik konsistent. Nutzer, die eine Website des Systems kennen, finden sich auf jeder anderen zurecht. ## 4. Frontend-Architektur-Design ### 4.1 Seitenhierarchie Die Basis-Seitenhierarchie umfasst: - Startseite - Über uns - Produkte / Dienstleistungen - Kontakt - Blog / News - FAQ - Karriere / Team - Individuelle Erweiterungsseiten Jede Seite hat eine definierte Struktur aus Sektionen. Die Startseite ist als Sammlung von Sektionen konfigurierbar. Alle anderen Seiten folgen festen Vorlagen mit konfigurierbaren Inhalten. ### 4.2 Komponentenmodule Diese Komponenten werden als wiederverwendbare Bausteine abstrahiert: - Header (mit Navigation, Logo, Sprachumschalter) - Footer (mit Links, Social Media, rechtlichen Informationen) - Banner (Hero-Bereich mit Titel, Untertitel, CTA) - Features (Feature-Grid mit Icons und Beschreibungen) - CTA (Call-to-Action-Bereich) - Testimonials (Kundenstimmen) - Formulare (Kontakt, Newsletter, Anfrage) - Cards (Produktkarten, Teammitglieder, Blog-Posts) - FAQ (Akkordeon) - Modal / Drawer / Notification (für Interaktionen) Jede Komponente akzeptiert Konfigurationsobjekte für Inhalte und Stile. Komponenten haben keine fest codierten Texte oder Bilder. ### 4.3 Konfigurierbare Elemente Diese Frontend-Elemente sind konfigurierbar: - Logo (Bild, Größe, Position) - Farben (Primär, Sekundär, Akzent, Hintergrund, Text) - Schriftarten (Familie, Größen, Gewichte) - Button-Stile (Form, Farbe, Hover-Zustand) - Bild-Assets (Hero-Bilder, Teamfotos, Produktbilder) - Texte/Kopien (alle sichtbaren Texte) - Seiten-Sektionsreihenfolge (auf der Startseite) - Modul-Schalter (jedes Modul kann aktiviert/deaktiviert werden) - Mehrsprachige Inhalte (Sprachumschalter, Übersetzungen) ### 4.4 Responsive Design und Interaktion Mobile-First-Strategie: Alle Komponenten werden zuerst für mobile Bildschirme entworfen. Tablet- und Desktop-Adaptionen erweitern das Layout schrittweise. Ladezustände werden für alle datengetriebenen Komponenten definiert. Leere Zustände zeigen sinnvolle Platzhalter. Fehlerzustände bieten klare Handlungsoptionen. Konsistenz wird durch die zentrale Komponentenbibliothek erreicht. Wartbarkeit durch strikte Trennung von Logik, Stil und Inhalt. ### 4.5 Empfohlener Frontend-Technologie-Ansatz **Next.js** ist die empfohlene Wahl. Gründe: - Server-Side Rendering für SEO-Leistung, wichtig für Unternehmenswebsites - Integriertes Routing, das die Seitenhierarchie direkt abbildet - API-Routen für einfache Backend-Anbindung - Große Ökosystem-Unterstützung - TypeScript-Unterstützung für Typsicherheit - Einfache Deployment-Möglichkeiten auf verschiedenen Plattformen React als reine Bibliothek ist möglich, erfordert aber zusätzliche Setup-Arbeit für Routing und SSR. Vue ist eine Alternative, hat aber ein kleineres Ökosystem für SSR-Anwendungen. Reines HTML/CSS/JavaScript ist für ein wiederverwendbares System mit vielen Instanzen nicht wartbar. ## 5. Backend-Architektur-Design ### 5.1 Backend-Verantwortlichkeiten Das Backend übernimmt: - Konfigurationsverwaltung (Laden, Validieren, Bereitstellen von Site-Konfigurationen) - Formularverarbeitung (Validierung, Speicherung, Benachrichtigung) - Benutzerdaten (falls Anmeldung oder personalisierte Inhalte benötigt werden) - Content-Management (CRUD für Seiteninhalte, Blog-Posts, FAQ-Einträge) - Admin-APIs (für das Verwaltungsinterface) - Berechtigungskontrolle (Rollen, Zugriffsrechte) - Drittanbieter-Integrationen (Analytics, CRM, Newsletter-Dienste) - Logging und Monitoring (Fehlerverfolgung, Leistungsüberwachung) ### 5.2 Technologieauswahl-Empfehlungen **Node.js mit NestJS** ist die empfohlene Wahl. Gründe: - Entwicklungseffizienz: TypeScript durchgängig, modulare Struktur, klare Abhängigkeitsinjektion - Wartbarkeit: Strukturierte Ordner, klare Modulgrenzen, Testbarkeit - Ökosystem-Reife: Umfangreiche Bibliotheken für alle gängigen Backend-Aufgaben - Wiederverwendbarkeit: Module können als Pakete für verschiedene Template-Instanzen gebündelt werden - Frontend-Kollaboration: Gleiche Sprache (TypeScript) reduziert Kontextwechsel Python mit Django oder FastAPI ist eine Alternative, besonders wenn das Team Python bevorzugt. Django bietet ein integriertes Admin-Interface, was für Content-Management nützlich ist. FastAPI ist leichtgewichtiger, erfordert aber mehr Setup für Admin-Funktionen. ### 5.3 API-Design-Ansatz Gemeinsame APIs werden abstrahiert: - `GET /api/site-config` - liefert die komplette Site-Konfiguration - `GET /api/pages/:slug` - liefert Seiteninhalte - `POST /api/forms/:formType` - verarbeitet Formulare - `GET /api/blog/posts` - Blog-Liste - `GET /api/faq` - FAQ-Einträge - `POST /api/auth/login` - Admin-Authentifizierung Geschäftsspezifische APIs werden als Erweiterungsmodule hinzugefügt. Jedes Modul registriert seine eigenen Routen unter einem Modul-Präfix, z.B. `/api/booking/...` für Buchungsfunktionen. Wiederverwendung wird durch eine zentrale API-Schicht erreicht, die gemeinsame Logik (Validierung, Authentifizierung, Fehlerbehandlung) bereitstellt. Neue Module erben diese Basis. Unkontrollierte Kopplung wird durch strikte Modulgrenzen verhindert. Module kommunizieren nicht direkt miteinander, sondern nur über definierte Schnittstellen. ### 5.4 Daten- und Berechtigungsdesign Die Kern-Datenobjekte: - **Site-Konfiguration**: Enthält Markenparameter, Modul-Schalter, globale Einstellungen. Als JSON-Dokument gespeichert. - **Seiteninhalt**: Strukturierte Inhalte für jede Seite. Als JSON-Dokumente mit Schema-Validierung. - **Formulardaten**: Eingaben aus Kontakt-, Newsletter- und Anfrageformularen. Als strukturierte Datensätze. - **Benutzer/Administratoren**: Für Admin-Zugang. Mit Rollen (Super-Admin, Content-Manager, Viewer). - **Modulstatus**: Aktiviert/deaktiviert pro Instanz. Teil der Site-Konfiguration. - **Multi-Brand-Konfigurationsisolation**: Jede Instanz hat ihre eigene Datenbank oder zumindest eigene Schemata. Keine Vermischung von Mandantendaten. ## 6. Template-Anpassungsmechanismus ### 6.1 Marken-Level-Anpassung - **Unternehmensname**: Konfigurierbar, wird in Header, Footer, SEO-Tags und Metadaten verwendet - **Logo**: Bild-Asset wird über Konfiguration referenziert - **Farbpalette**: CSS-Variablen werden aus Konfiguration generiert - **Schriftarten**: Font-Familien werden über Konfiguration geladen - **Bildstil**: Richtlinien für Bildauswahl, keine technische Konfiguration - **Marken-Tonalität**: Textvorlagen und Formulierungsrichtlinien, keine technische Konfiguration ### 6.2 Seiten-Level-Anpassung - **Seitenanzahl**: Seiten können über Konfiguration hinzugefügt oder entfernt werden - **Seitenreihenfolge**: Navigation wird aus Konfiguration generiert - **Seitenvorlagen-Wiederverwendung**: Jede Seite nutzt eine Vorlage (Standard, Blog, FAQ, Kontakt) - **Startseiten-Sektionskomposition**: Reihenfolge und Auswahl der Sektionen ist konfigurierbar - **Inhaltsblöcke**: Hinzufügen/Entfernen von Inhaltsblöcken innerhalb von Seiten ### 6.3 Funktions-Level-Anpassung - **Kontaktformulare**: Aktivierbar/deaktivierbar, Felder konfigurierbar - **Produktpräsentation**: Modul für Produktkarten, konfigurierbar - **Service-Buchung**: Erweiterungsmodul, nur bei Bedarf aktiviert - **Blog**: Aktivierbar/deaktivierbar, mit Kategorien und Tags - **FAQ**: Aktivierbar/deaktivierbar, mit Kategorien - **Admin-Panel**: Immer verfügbar, aber mit unterschiedlichen Berechtigungen - **Mehrsprachigkeit**: Aktivierbar, Sprachen konfigurierbar - **SEO**: Automatisch aus Konfiguration, mit manuellen Überschreibungen - **Drittanbieter-Integrationen**: Konfigurierbar über Umgebungsvariablen ### 6.4 Konfigurationsmethoden-Empfehlungen - **Konfigurationsdateien (JSON/YAML)**: Für statische Struktur - Seitenhierarchie, Moduldefinitionen, Komponentenkonfiguration. Versionierbar, testbar, keine Datenbank erforderlich. - **CMS**: Für redaktionelle Inhalte - Blog-Posts, FAQ-Einträge, Team-Beschreibungen. Nicht-technische Benutzer können Inhalte pflegen. - **Datenbank**: Für dynamische Daten - Formulareingaben, Benutzerkonten, Buchungsdaten. Transaktional, skalierbar. - **Admin-Verwaltungssystem**: Für Site-Konfiguration - Markenparameter, Modul-Schalter, Seiten-Sektionen. Bietet UI für Konfiguration ohne Code. ## 7. Multi-Industrie-Anpassungsempfehlungen ### Technologieunternehmen - **Unverändert**: Seitenhierarchie, Komponentenbibliothek, Backend-Struktur - **Visuelle Anpassung**: Dunkle Farbschemata, technische Bildsprache, moderne Typografie - **Funktionale Anpassung**: Produktpräsentation mit technischen Spezifikationen, API-Dokumentation als Erweiterungsmodul - **Kosten**: Gering, da Standardmodule weitgehend passen ### Einzelhandelsunternehmen - **Unverändert**: Seitenhierarchie, Komponentenbibliothek, Backend-Struktur - **Visuelle Anpassung**: Helle, freundliche Farben, Produktfotografie, verspielte Typografie - **Funktionale Anpassung**: Produktkatalog mit Kategorien, Newsletter-Anmeldung, Standortfinder - **Kosten**: Mittel, da Produktpräsentation umfangreicher ist ### Dienstleistungsunternehmen - **Unverändert**: Seitenhierarchie, Komponentenbibliothek, Backend-Struktur - **Visuelle Anpassung**: Vertrauenswürdige Farben, Teamfotos, klare Typografie - **Funktionale Anpassung**: Buchungssystem, Leistungsübersicht, Referenzprojekte - **Kosten**: Gering, da Standardmodule weitgehend passen ### Web3/Blockchain-Projekte - **Unverändert**: Seitenhierarchie, Komponentenbibliothek, Backend-Struktur - **Visuelle Anpassung**: Futuristische Ästhetik, Gradienten, abstrakte Visuals - **Funktionale Anpassung**: Wallet-Verbindung, Token-Informationen, Roadmap-Modul - **Kosten**: Mittel, da spezifische Web3-Funktionen als Erweiterungsmodule gebaut werden müssen ## 8. Engineering-Standards und Best Practices **Verzeichnis-Konventionen**: Klare Trennung von `src`, `config`, `tests`, `public`. Innerhalb von `src` nach Feature-Modulen organisieren, nicht nach technischer Funktion. **Benennungs-Konventionen**: Komponenten in PascalCase, Funktionen in camelCase, Konstanten in UPPER_SNAKE_CASE. Dateinamen entsprechen dem exportierten Symbol. **Style-Management-Konventionen**: CSS-Module oder Styled-Components. Keine globalen Styles außer Design-Tokens. Design-Tokens (Farben, Abstände, Typografie) als zentrale Konfiguration. **API-Konventionen**: RESTful mit klaren Ressourcen-Namen. JSON als Austauschformat. Fehler als strukturierte Objekte mit Code und Nachricht. Versionierung über URL-Präfix. **Konfigurationsmanagement-Konventionen**: Konfiguration in JSON-Dateien mit Schema-Validierung. Umgebungsvariablen für Secrets und Umgebungs-spezifische Werte. Keine Konfiguration im Code. **Umgebungsvariablen-Konventionen**: Präfix `TEMPLATE_` für alle Variablen. Pflicht-Variablen dokumentiert. Fehlende Variablen führen zu klaren Fehlermeldungen beim Start. **Kommentar- und Dokumentations-Konventionen**: JSDoc für alle exportierten Funktionen. README pro Modul. Architektur-Dokumentation im `docs`-Verzeichnis. Keine Kommentare, die Offensichtliches wiederholen. **Frontend-Backend-Kollaborations-Konventionen**: OpenAPI-Spezifikation als Single Source of Truth für API-Verträge. TypeScript-Typen werden aus OpenAPI generiert. Änderungen an APIs erfordern Spezifikations-Update zuerst. **Wartbarkeits-Empfehlungen**: Automatisierte Tests für kritische Pfade. CI/CD mit Linting, Type-Checking und Tests. Versionskontrolle mit klaren Commit-Konventionen. Regelmäßige Abhängigkeits-Updates. ## 9. Empfohlene Verzeichnisstruktur ``` / ├── frontend/ │ ├── src/ │ │ ├── components/ # Wiederverwendbare UI-Komponenten │ │ ├── pages/ # Seiten-Komponenten │ │ ├── hooks/ # Custom Hooks │ │ ├── lib/ # Utility-Funktionen │ │ └── styles/ # Design-Tokens, globale Styles │ ├── public/ # Statische Assets │ └── package.json ├── backend/ │ ├── src/ │ │ ├── modules/ # Feature-Module (auth, content, forms) │ │ ├── common/ # Geteilte Infrastruktur │ │ └── config/ # Backend-Konfiguration │ └── package.json ├── config/ │ ├── site.default.json # Standard-Site-Konfiguration │ ├── site.custom.json # Individuelle Site-Konfiguration │ └── schemas/ # JSON-Schemas für Validierung ├── assets/ │ ├── images/ # Standard-Bild-Assets │ ├── fonts/ # Standard-Schriftarten │ └── logos/ # Platzhalter-Logos ├── shared/ │ ├── types/ # Geteilte TypeScript-Typen │ ├── api/ # API-Spezifikationen │ └── utils/ # Geteilte Utility-Funktionen └── docs/ ├── architecture.md # Architektur-Übersicht ├── configuration.md # Konfigurations-Dokumentation └── development.md # Entwicklungs-Setup ``` Jede Schicht hat klare Verantwortlichkeiten: `frontend` für UI, `backend` für API und Daten, `config` für alle Konfigurationen, `assets` für statische Ressourcen, `shared` für geteilten Code, `docs` für Dokumentation. ## 10. MVP-Entwicklungsprioritäten ### Phase 1: Minimal lebensfähiges Skelett - Grundlegende Seitenhierarchie (Startseite, Über uns, Kontakt) - Kernkomponenten (Header, Footer, Banner, CTA, Formular) - Konfigurationsmechanismus für Markenparameter - Backend mit Site-Konfiguration und Formular-API - Eine Referenz-Instanz für ein Technologieunternehmen **Warum zuerst**: Diese Elemente bilden das Fundament. Ohne sie kann nichts anderes funktionieren. Sie lösen das Kernproblem der Wiederverwendbarkeit. **Wert für Template-Wiederverwendung**: Das Skelett ist die Grundlage für alle zukünftigen Instanzen. Es validiert die Architektur und zeigt, ob die Konfigurationsmechanismen funktionieren. ### Phase 2: Erweiterte Erfahrung und Erweiterbarkeit - Blog-Modul - FAQ-Modul - Produktpräsentation - Mehrsprachigkeit - Admin-Panel für Inhaltsverwaltung - Erweiterte Seitenvorlagen **Warum als zweites**: Diese Module decken die häufigsten Anforderungen ab. Sie erweitern die Abdeckung auf mehr Unternehmenstypen. **Wert für Template-Wiederverwendung**: Mehr Module bedeuten mehr Abdeckung. Die Erweiterbarkeitsmechanismen werden durch reale Module validiert. ### Phase 3: Fortgeschrittene Fähigkeiten und langfristige Evolution - Buchungssystem - Web3-Integrationen - Erweiterte SEO-Funktionen - Analytics-Integration - A/B-Testing-Framework - Performance-Optimierung **Warum als letztes**: Diese Funktionen sind spezifischer und betreffen weniger Unternehmen. Sie sollten nur bei Bedarf gebaut werden. **Wert für Template-Wiederverwendung**: Diese Phase zeigt, dass das System über die Grundbedürfnisse hinaus wachsen kann. Sie validiert die langfristige Wartbarkeit. ## 11. Risiken und Grenzen **Übergeneralisierung führt zu schwacher Markenidentität**: Wenn das Template zu abstrakt ist, wirken alle Websites gleich. **Gegenmaßnahme**: Klare Design-Tokens und flexible Layout-Optionen. Marken-spezifische Anpassungen müssen ohne Architekturänderung möglich sein. **Übermäßige Konfigurierbarkeit erhöht die Systemkomplexität**: Jede Konfigurationsoption muss dokumentiert, getestet und gewartet werden. **Gegenmaßnahme**: Konfiguration nur für Elemente, die tatsächlich variieren. Standardwerte für alles andere. Konfigurations-Schemas mit Validierung. **Übergewichtiges Backend macht das MVP zu teuer**: Zu viele Funktionen in der ersten Version verzögern den Start. **Gegenmaßnahme**: MVP auf das Minimum beschränken. Backend-Funktionen nur bei konkretem Bedarf hinzufügen. **Große Branchenunterschiede reduzieren die Template-Adaptionseffizienz**: Wenn Branchen zu unterschiedlich sind, wird die Anpassung teurer als eine Neuentwicklung. **Gegenmaßnahme**: Klare Grenzen definieren, welche Branchen abgedeckt werden. Für sehr spezifische Branchen eigene Module bauen, nicht das Kern-Template verbiegen. ## 12. Abschließende Schlussfolgerung **Gesamtansatz**: Ein modulares Template-System mit klarer Trennung zwischen fixem Skelett und konfigurierbaren Teilen. Die Architektur priorisiert Wiederverwendbarkeit über individuelle Anpassung. **Empfohlener Technologie-Stack**: Next.js für das Frontend, Node.js mit NestJS für das Backend, TypeScript durchgängig, PostgreSQL als Datenbank, JSON-Konfigurationsdateien mit Schema-Validierung. **Erste Version**: Das minimal lebensfähige Skelett mit Kernseiten, Kernkomponenten und Konfigurationsmechanismus. Eine Referenz-Instanz für ein Technologieunternehmen. **Zukünftiger Erweiterungspfad**: Blog, FAQ, Produktpräsentation, Mehrsprachigkeit, Admin-Panel. Danach branchenspezifische Module wie Buchungssystem oder Web3-Integrationen. **Größter Vorteil**: Die Wiederverwendbarkeit. Einmal gebaute Architektur, Komponenten und Backend-Struktur werden für jede neue Website wiederverwendet. Die Kosten pro Website sinken drastisch. **Größte Vorsicht**: Übergeneralisierung. Das System muss flexibel genug für verschiedene Marken sein, aber nicht so abstrakt, dass es keine klare Identität ermöglicht. Die Balance zwischen Konfigurierbarkeit und Einfachheit ist der kritischste Punkt.