Aller au contenu

Multi‑tenancy & Tenants (dynors-db)

Objectif : donner une vue synthétique de la façon dont dynors-db gère les tenants, les tiers et les stratégies d’isolation.

Pour les détails complets, voir core/packages/core/db/README.md.

Concept clé : le Tenant

Un tenant = un "client" au sens large (entreprise cliente, produit, outil interne) avec ses propres données et quotas.

Exemples : - seckshop : projet ESN pour une boutique. - miamcampus_senegal : produit édité déployé pour un pays. - jokko_internal : CRM interne DYNORS.

Tiers & stratégies d’isolation

dynors-db gère :

  • Tiers de service : FREE, TIER_3, TIER_2, TIER_1, SOVEREIGN.
  • Stratégies d’isolation :
  • SHARED → base partagée + colonne tenant_id.
  • SCHEMA_DEDICATED → schéma dédié par tenant.
  • DATABASE_DEDICATED → base dédiée par tenant.

Règle importante (version actuelle) : - Projets clients ESN (CLIENT_PROJECT) : au minimum SCHEMA_DEDICATED (jamais SHARED). - Produits édités critiques : souvent DATABASE_DEDICATED.

Où intervient TAKKU ?

  • TAKKU appelle TenantService (dynors-db) pour créer un tenant :
  • type (INTERNAL_TOOL, CLIENT_PROJECT, DYNORS_PRODUCT, ...),
  • tier,
  • stratégie d’isolation.
  • TenantInitializationService s’occupe de :
  • créer le schéma ou la base,
  • appliquer les migrations (Flyway),
  • préparer les quotas par défaut.

L’application cliente ne crée pas le tenant : elle consomme celui que TAKKU a créé.

Tenants & schémas côté projet client

Pour un projet client typique (SeckShop) :

  • Base physique (ex) : dynors_production.
  • Schéma : tenant_seckshop.
  • Les entités JPA de l’app sont mappées sur des tables de ce schéma.
  • Le développeur :
  • ne manipule pas tenant_id directement,
  • se contente d’utiliser TenantAwareRepository et le TenantContext géré par dynors-db.

Client vs Users

Rappel important (extrait de CLIENT_VS_USERS.md) :

  • Client / Tenant = qui paie (ex : SeckShop SARL).
  • Users = qui utilise (ex : employés de SeckShop, clients finaux).

dynors-db gère les tenants et leurs quotas (stockage, nombre d’utilisateurs, etc.).
Les applications métier gèrent la logique fonctionnelle pour les utilisateurs finaux.