Next.js · React · TypeScript
Partez d'une architecture définie, pas d'un dépôt vide.
Foundation est une base de site web pilotée par la configuration, avec un cœur indépendant du framework, des ports et des adaptateurs, une configuration validée par schéma et une vraie porte de vérification. Vous héritez des fondations et consacrez votre temps aux parties réellement propres au site que vous construisez.
- Next.js App Router avec React Server Components
- TypeScript partout, avec une configuration validée par schéma
- Des portes de tests unitaires, d'architecture et de vrais navigateurs dans le dépôt
L'architecture en un coup d'œil
Quatre étapes avec un sens de dépendance unique. Les deux centrales sont la base ; la première et la dernière sont les vôtres.
- Stage 1
Données du site, contenu et ressources
Identité, navigation, langues, contenu Markdown et illustrations — les entrées propres à l'adoptant, validées avant que quoi que ce soit les lise.
- Stage 2
Environnement dérivé de Foundation
Des concepts métier indépendants du framework et les services applicatifs qui les orchestrent, sans import du framework.
- Stage 3
Présentation, routage et points d'intégration
Routes, composition de la mise en page, métadonnées et les fabriques d'adaptateurs qui relient réservation, demandes, cartes et mesure d'audience depuis la configuration.
- Stage 4
Déploiement
Une compilation orientée génération statique, déployée depuis votre propre dépôt vers votre propre compte d'hébergement.
Le sens des dépendances est affirmé par des tests plutôt que supposé : le cœur ne peut pas importer React, Next.js ni une couche externe, et la couche applicative ne peut pas atteindre un adaptateur concret.
Configurer, ou coder
Cette frontière est le cœur du projet. La plupart des décisions propres à l'entreprise sont des données ; les vraies extensions sont du code, et Foundation dit clairement ce qui est quoi.
Généralement configuré ou rédigé
- Identité : nom, slogan, description et URL canonique
- La navigation, et le groupe secondaire ou de pied de page
- L'ensemble des langues et les dictionnaires d'interface
- Les régions de l'entreprise, les horaires et les itinéraires
- Le contenu : pages et collections en Markdown
- L'image de marque, les icônes et les visuels
- Le choix des fournisseurs pour la réservation, les demandes, les cartes et la mesure d'audience
- L'activation des fonctionnalités pour les offres, le portfolio, le blog et les témoignages
- Les valeurs de présentation exposées par le contrat de configuration
Nécessite du code pour étendre réellement le comportement
- Un nouvel adaptateur de fournisseur pour une capacité existante
- Une nouvelle capacité réutilisable
- Un nouveau comportement ou une nouvelle interaction d'interface
- Un nouveau module applicatif en aval
- Tout ce qui sort des frontières de configuration établies
La position approuvée : l'essentiel de l'identité, du contenu, de l'image de marque et du choix des fonctionnalités vit hors du cœur applicatif. Cela ne promet pas qu'aucun code ne sera jamais écrit — une capacité réellement nouvelle est un travail de plateforme, et Foundation le dit au lieu de laisser croire qu'un système de greffons existe.
Le contrat d'ingénierie
Ce à quoi le projet s'engage — et ce qu'il refuse d'affirmer.
Configuration strictement validée
Un schéma, les clés inconnues rejetées, des échecs exploitables, et une configuration lisible uniquement via le chargeur.
Frontières hexagonales
Un cœur pur, des ports et services applicatifs, des adaptateurs derrière des fabriques, et des routes de framework fines.
Application des dépendances
Les tests d'architecture parcourent l'arbre source et échouent sur un import interdit, si bien que le schéma ne peut pas s'éloigner du code.
Composition côté serveur d'abord
React Server Components et génération statique par défaut, l'interactivité cliente étant limitée aux composants qui en ont besoin.
Vérification dans de vrais navigateurs
Une matrice de navigateur sans interface, versionnée, couvre les largeurs bureau, tablette et mobile, l'interaction clavier et pointeur, le mouvement réduit et le schéma sombre, et fait échouer l'exécution à la moindre assertion non tenue.
Portes d'architecture et unitaires
Les tests de frontières et unitaires s'exécutent à côté du contrôle des ressources, du contrôle des types, du lint et de la compilation de production.
Discipline des affirmations de capacité
Les affirmations documentées sont confrontées au registre interne du projet, si bien qu'une affirmation ne peut pas dépasser ses preuves.
Un modèle de mise à niveau honnête
Parce que votre configuration, votre contenu et vos ressources vivent hors du cœur applicatif, les améliorations de la plateforme peuvent être absorbées au lieu d'écraser votre travail.
Ce que le projet n'affirme pas
Foundation n'affirme aucune conformité WCAG, aucune certification de sécurité, aucun test d'intrusion, aucun score de performance ou Lighthouse publié, aucune couverture universelle des navigateurs et appareils. L'accessibilité et la performance sont conçues et vérifiées là où le projet peut les vérifier — elles ne sont pas certifiées.
Où Foundation s'arrête
La même répartition de propriété, formulée techniquement. Foundation s'arrête délibérément avant la complexité opérationnelle et fournit le point d'intégration vers le service que vous choisissez.
Propriété de l'adoptant
- Configuration
- Contenu
- Dictionnaires de langue
- Illustrations de l'entreprise
- Choix des fournisseurs
- Extensions en aval
Propriété de Foundation
- Architecture applicative
- Mécanique d'interface réutilisable
- Validation de la configuration
- Mécanique de routage et de contenu
- Points d'intégration
- Infrastructure de vérification
L'extension se fait de l'extérieur vers l'intérieur : un nouveau fournisseur est un adaptateur, une branche de fabrique et une entrée d'énumération de schéma ; un nouveau type de contenu ou une nouvelle langue sont des données. Une capacité réellement nouvelle est un travail de plateforme.
Flux d'adoption
Huit étapes. Le dépôt détient le détail au niveau des commandes — ceci en est la forme.
- 1
Obtenir Foundation
Clonez ou forkez le dépôt public.
- 2
Installer et exécuter
Installez les dépendances et démarrez le site localement.
- 3
Configurer
Définissez l'identité, les langues, les fonctionnalités et les fournisseurs.
- 4
Rédiger le contenu et les ressources
Écrivez vos pages et remplacez les rôles de ressources de marque.
- 5
Connecter les fournisseurs
Pointez les points d'intégration vers les services que vous utilisez réellement.
- 6
Valider
Exécutez localement la porte de qualité du projet.
- 7
Déployer
Compilez et déployez depuis votre propre dépôt et votre propre compte.
- 8
Maintenir et mettre à niveau
Absorbez les améliorations amont sans écraser votre matière.
Les manuels du dépôt couvrent chaque étape, y compris le dépannage.
Documentation de référence
GitHub est la source technique canonique. Ce site web résume ; le dépôt instruit.
Repository
Le code complet, sa licence, et la déclaration du projet sur ce qu'il est et n'est pas.
README.md
Ce qu'est le projet, démarrage rapide, organisation du dépôt et position sur la licence.
ARCHITECTURE.md
Style architectural, frontières, sens des dépendances et motifs d'intégration.
CUSTOMIZING.md
Le guide de l'utilisateur en aval et la référence complète de configuration.
DEPLOYMENT.md
Le runbook de lancement et la liste de vérification après déploiement.
BRAND_ASSETS.md
Le contrat de remplacement des ressources de marque : chaque rôle graphique remplaçable.
Manuels
Les procédures d'adoption, de personnalisation, d'image de marque, de contenu, de mise à niveau, de validation, de déploiement et de dépannage.
Chaque destination ci-dessus est un lien vers le dépôt public, où ces documents sont maintenus.
Lisez-le, exécutez-le, modifiez-le
Le code, ses tests et sa documentation sont l'argument. Commencez là.