Aller au contenu

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

Référence historique — choix de versions explicite

Avant tout bootstrap, consulter la matrice actuelle Boot 3/4, bases, BOM et correctifs et le contrat DB actuel. Les exemples historiques ne prouvent ni compatibilité Spring 7, ni disponibilité d'un BOM Boot 4, ni isolation automatique, ni readiness d'une application.

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.7"))  // 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.1")
    // 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. Gradle : registry GitLab — voir CONFIGURATION_ACCES_DEPENDANCES.md (workspace dynors) et config/dynors-repositories.gradle.kts. Maven : Maven — settings.xml & registry GitLab.

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.