Project architecture

Vue globale de l’architecture du monorepo et des différentes couches du projet.

Project structure

Vue synthétique de l’arborescence du monorepo.

  • 📁apps
    • 📁mobile
    • 📁web
  • 📁assets
    • 📁css
  • 📁packages
    • 📁backend
    • 📁config
    • 📁contracts
    • 📁finder-core
  • 📁prisma
    • 📁migrations

Project architecture

Cette page présente l’architecture globale du projet.

L’objectif n’est pas seulement de décrire des dossiers, mais de comprendre comment les différentes couches collaborent pour construire une application complète.

Le projet est organisé comme un monorepo, permettant de regrouper :

  • le frontend
  • le backend
  • les contrats partagés
  • la documentation

Vue rapide du monorepo#

Project structure

Vue synthétique de l’arborescence du monorepo.

  • 📁apps
    • 📁mobile
    • 📁web
  • 📁assets
    • 📁css
  • 📁packages
    • 📁backend
    • 📁config
    • 📁contracts
    • 📁finder-core
  • 📁prisma
    • 📁migrations

Cette vue donne une représentation concrète du repository.

Chaque dossier correspond à une responsabilité claire, ce qui permet de structurer le projet de manière scalable.

Architecture logique du projet#

apps/web

Frontend Next.js, rendu des pages, docs, UI.

apps/web/content/docs

Contenu MDX pédagogique et documentation produit.

packages/backend

Routers tRPC, logique serveur, accès Prisma, auth.

packages/contracts

Schémas Zod et types partagés entre client et serveur.

prisma

Modèle de données, migrations et structure BDD.

L’architecture repose sur une séparation forte entre :

  • présentation (frontend)
  • transport (tRPC)
  • logique métier (backend modules)
  • accès aux données (Prisma / Cloudinary / email)

Flux global de l’application#

No diagram steps provided.

Lorsqu’un utilisateur effectue une action :

  1. le client React déclenche une requête
  2. la requête est envoyée au router tRPC
  3. le router appelle un module métier
  4. le module délègue la logique à des services
  5. les services interagissent avec :
    • la base de données via Prisma
    • le stockage via Cloudinary
    • ou des services externes comme email

Organisation du monorepo#

apps/web#

Application frontend basée sur Next.js.

Elle est structurée par features, ce qui permet de regrouper :

  • les composants
  • les formulaires
  • les hooks
  • les actions serveur

Chaque feature correspond à un domaine fonctionnel (auth, admin, pictures, etc.).

La documentation MDX est également intégrée ici, ce qui permet de créer une doc vivante directement connectée au code.

packages/backend#

Le backend est organisé autour d’un dossier central :

modules/

Chaque module représente un domaine métier :

  • auth
  • users
  • roles
  • permissions
  • categories
  • courses
  • trash
  • uploads
  • cloudinary

Chaque module contient généralement :

  • un router tRPC
  • éventuellement des services métier
  • des utilitaires liés au domaine

Exemple

modules/trash/
  router.ts
  services/
  utils.ts

Cette approche permet :

  • une forte cohérence métier
  • une meilleure scalabilité
  • une maintenance facilitée

Infrastructure backend#

En dehors des modules, le backend contient aussi des couches transverses :

trpc/

  • définition du contexte
  • middlewares
  • configuration des procédures

lib/

  • utilitaires techniques (auth, sécurité, session)

email/

  • templates
  • services d’envoi

middlewares/

  • middlewares globaux (ex: requireAdmin)

packages/contracts#

Ce package centralise :

  • les schémas Zod
  • les types TypeScript
  • les contrats d’API

Il garantit que :

  • le frontend et le backend partagent exactement les mêmes types
  • les validations sont unifiées

👉 C’est un élément clé pour éviter les erreurs de synchronisation.

prisma#

Contient le modèle de données :

  • schema.prisma
  • les migrations
  • la configuration de la base

Prisma est utilisé comme couche d’accès aux données par les services backend.

Pourquoi cette architecture ?#

Séparation claire des responsabilités#

Chaque couche a un rôle précis :

  • UI → frontend
  • transport → tRPC
  • logique → modules backend
  • données → Prisma / Cloudinary

Architecture modulaire#

Les modules backend permettent de :

  • isoler chaque domaine métier
  • ajouter facilement de nouvelles fonctionnalités
  • éviter les dépendances croisées

Partage de types sécurisé#

Grâce à packages/contracts :

  • aucune duplication de types
  • validation cohérente entre client et serveur

Scalabilité#

Cette architecture permet :

  • d’ajouter de nouveaux modules sans casser l’existant
  • de faire évoluer le projet vers un SaaS complet

Ce qu’il faut retenir#

  • le projet est structuré autour des domaines métier
  • tRPC agit comme couche de transport typée
  • Prisma gère l’accès aux données
  • les modules backend centralisent la logique
  • le frontend est organisé par features

👉 L’ensemble forme une architecture cohérente, maintenable et évolutive.

Navigation dans l’architecture#

Pour approfondir :

  • voir la section Domain
  • voir la section Patterns
  • suivre les Tutorials
Previous
← Architecture Map
Next
Technology Stack →
On this page