Aller au contenu

Guide Projets Clients & dynors-core (version synthèse)

Cette page résume le document interne core/GUIDE_UTILISATION_CORE_PROJETS_CLIENTS.md en se concentrant sur ce qu’un architecte ou dev doit faire concrètement pour démarrer une app client.

Pour les détails complets et tous les exemples de code, se référer au dépôt principal : core/TAKKU_INTEGRATION_GUIDE.md, core/ARCHITECTURE.md, et Documentation source (core).

1. Rappels d’architecture

  • Tous les projets clients s’appuient sur :
  • dynors-db pour le multi‑tenant (tenants, tiers, schémas, quotas).
  • dynors-security pour l’authentification & autorisation (JWT, OAuth2, DB auth).
  • dynors-commons pour les utilitaires & exceptions.
  • dynors-logging pour les logs centralisés.
  • Les tenants sont créés et configurés par TAKKU. L’application cliente consomme ensuite le tenant affecté.

2. Dépendances à ajouter

Dans le build.gradle.kts du projet client :

dependencies {
    implementation(platform("com.dynors:dynors-core-bom:1.0.2"))  // Dernière release — voir [Versions et dépendances](../99-annexes/versions-et-dependances.md)

    implementation("com.dynors:dynors-commons")
    implementation("com.dynors:dynors-security")
    implementation("com.dynors:dynors-db")
    implementation("com.dynors:dynors-logging:1.0.0-SNAPSHOT")
    // Optionnel : implementation("com.dynors:dynors-billing") si abonnements

    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation("org.springframework.boot:spring-boot-starter-data-jpa")
    implementation("org.springframework.boot:spring-boot-starter-security")
    implementation("org.postgresql:postgresql")
}

Versions release à jour : Versions et dépendances. Configuration du repository GitLab Maven Registry : CONFIGURATION_ACCES_DEPENDANCES.md (repo principal) ou CONFIGURATION_CLIENT_PROJETS.md.

3. Configuration Spring Boot minimale

  1. Classe Application : inclure les packages core dans scanBasePackages, @EntityScan, @EnableJpaRepositories.
  2. application.yml :
  3. Datasource PostgreSQL
  4. dynors.db : multi-tenant=true, default-strategy=schema, default-tier=TIER_2
  5. dynors.security : JWT activé, features selon le besoin
  6. dynors.logging : provider=console en dev, provider=sentry en prod.

4. Entités & Repositories

  • En stratégie SCHEMA_DEDICATED (cas des projets clients), les entités n’ont pas besoin de tenant_id : l’isolation se fait par schéma.
  • Les repositories doivent étendre TenantAwareRepository<Entité, UUID> pour bénéficier de l’isolation automatique.

Exemple :

@Entity
@Table(name = "customers")
public class Customer { /* ... */ }

@Repository
public interface CustomerRepository extends TenantAwareRepository<Customer, UUID> {
    Optional<Customer> findByEmail(String email);
}

5. Services métier & TenantContext

  • Utiliser TenantContextService pour :
  • récupérer le tenant courant,
  • éventuellement l’exposer dans les logs ou les règles métier.
@Autowired
private TenantContextService tenantContextService;

public String getCurrentTenantCode() {
    return tenantContextService.getCurrentTenant();
}

6. Sécurité (dynors-security)

  • Configurer Spring Security pour utiliser :
  • un endpoint /api/auth/login qui génère un JWT via JwtTokenProvider.
  • un filtre JwtAuthFilter fourni par dynors-security.
  • Les règles d’accès (URL, rôles, permissions) sont pilotées par TenantSecurityConfiguration et peuvent être configurées par TAKKU.

Idée clé : vos apps clients ne gèrent pas LDAP. LDAP est réservé aux apps internes (RAGNAR, TAKKU). Les apps clients utilisent dynors-security (JWT/OAuth2/DB).

7. Logging centralisé (dynors-logging)

  • Injecter DynorsLogger dans les services :
@Autowired
private DynorsLogger logger;
  • Utiliser info, warning, error, debug avec un contexte riche (tenant, service, action, ids métier).
  • Changer de provider (console → sentry → noop) se fait dans application.yml sans changer le code.

8. Migrations & tables (Flyway)

  • Placer les scripts dans src/main/resources/db/migration.
  • Ne pas créer de schéma dans les migrations : le schéma tenant est géré par dynors-db.
  • Les migrations créent uniquement les tables métier (customers, orders, etc.).

9. Checklist architecte pour un nouveau projet client

  • [ ] Tenant créé et configuré via TAKKU.
  • [ ] Projet créé (ou généré) avec dépendances core + logging.
  • [ ] application.yml conforme aux conventions dynors-db / dynors-security / dynors-logging.
  • [ ] Modèle métier isolé par schéma (pas de tenant_id manuel en SCHEMA_DEDICATED).
  • [ ] Authentification via dynors-security (pas de LDAP côté client).
  • [ ] Logging centralisé en place (au moins erreurs critiques + événements métier importants).
  • [ ] Migrations Flyway prêtes et testées sur un schéma tenant.
  • [ ] (Optionnel) Si abonnements : intégration dynors-billing — voir dynors-billing (Bibliothèque) et doc core/GUIDE_INTEGRATION_DYNORS_BILLING.md dans le repo.