Aller au contenu

Vision & architecture — Vue d’ensemble

Cette page synthétise la vision globale de l’écosystème DYNORS à partir des documents historiques du repo principal (docs/*.md, core/*.md, dynors-internal/*, jira/*).

L’objectif est que tout ce qui est utile au quotidien soit ici, dans la doc interne, avec des liens cliquables vers les sources détaillées.

1. Idée en une phrase

DYNORS = un socle technique partagé (dynors-core), une API de facturation unique (FISCAL), une comptabilité centralisée (DYNORS BOOKS), et des produits métier (SuperGest, TRACIUM, Mediconnect, DAWALALE, YOBALÉ, etc.) qui s’appuient sur ce socle et s’échangent des événements ou des appels API.

2. Où voir l’architecture rapidement

Ce que tu veux voir Où le trouver
Vue globale interactive (nœuds, liens, flux, matrice) Page Architecture & interactions (rubrique Plateforme Doc Technique)
Index des architectures + C4 par projet Section C4 par application (Mediconnect, SuperGest, TRACIUM, BOOKS, FISCAL, dynors-internal)
Stack & règles techniques communes Page Architecture & stack technique (backend, frontend, DB, événements, infra)
Gateway / routage (SelebeYone, SLY) Pages Gateway SelebeYone, Flux & routage complet, Config par app et Politique routage & auth inter-app
Contrat inter-apps (obligatoire) Page Contrat service appels inter-app
Tickets Jira + specs + design par app Section Préparation tickets Jira & backlogs

Les documents sources détaillés (docs/VUE_ENSEMBLE_ECOSYSTEME_DYNORS.md, docs/ARCHITECTURE_ET_STACK.md, etc.) sont référencés avec des liens directs GitLab dans l’annexe : Liens vers docs originaux.

3. Les briques principales

graph LR
    subgraph Socle
      CORE[dynors-core]
      SLY[SelebeYone (SLY)]
    end

    subgraph Services centraux
      FISCAL[FISCAL<br/>Facturation]
      BOOKS[DYNORS BOOKS<br/>Comptabilité]
    end

    subgraph Produits
      SG[SuperGest]
      TR[TRACIUM]
      MC[Mediconnect]
      DW[DAWALALE]
      YB[YOBALÉ]
      RG[RAGNAR]
    end

    CORE --> FISCAL
    CORE --> BOOKS

    SG --> FISCAL
    SG --> TR

    TR --> FISCAL
    TR --> BOOKS

    MC --> FISCAL
    MC --> TR
    MC --> DW

    DW --> FISCAL
    DW --> BOOKS

    YB --> FISCAL

    RG --> FISCAL

    SLY --- FISCAL
    SLY --- BOOKS
    SLY --- TR
    SLY --- SG
    SLY --- MC
    SLY --- DW
    SLY --- YB
    SLY --- RG

Ce schéma montre :

  • dynors-core comme socle technique consommé par FISCAL, BOOKS et toutes les apps.
  • FISCAL et BOOKS comme services centraux au cœur des flux financiers/comptables.
  • SelebeYone (SLY) comme gateway de routage vers tous les backends (internes et B2B).

4. Règle d’architecture

  • Vue globale : tout nouveau projet ou nouvelle dépendance doit être ajouté à la vue d’architecture des interactions (diagramme interactif).
  • C4 par projet : chaque application doit avoir un fichier C4 (Contexte + Conteneurs) qui décrit clairement :
  • les consommations (qui appelle qui) ;
  • les dépendances fortes (packages dynors-core / extensions) ;
  • les points d’intégration critiques (FISCAL, BOOKS, SLY, TRACIUM, etc.).
  • Cohérence : les C4 + la vue globale doivent être cohérents avec :
  • les guides d’intégration (FISCAL, billing, media, pdf, etc.) ;
  • les plans de développement (stabilisation, roadmap produits) ;
  • les backlogs Jira.

5. Sources détaillées (historique)

Pour les détails fins (textes longs, décisions, historique des tickets), voir l’annexe :

  • Liens vers documents techniques originaux — renvoie vers :
  • les .md du repo dynors (docs/*.md, jira/*.md) ;
  • les guides core/*.md (FISCAL, billing, media, pdf, TAKKU, etc.) ;
  • les docs dynors-internal (RAGNAR, TAKKU, FISCAL backend, etc.) ;
  • les backlogs Jira par projet.

Cette page reste volontairement synthétique : c’est le point d’entrée pour comprendre rapidement l’écosystème avant d’aller dans les pages détaillées (C4, stack technique, architecture SI, projets individuels).

Niveau 1 – Vision & Architecture Globale

Objectif : donner aux architectes et lead devs une vision claire de l’écosystème DYNORS.

Ce que vous allez voir

  • La séparation des 3 repos : dynors-core, dynors-internal, dynors-extensions (et dynors-platform).
  • Le rôle de RAGNAR, TAKKU, HEISENBERG, RED.
  • La notion de tenant et les types d’applications (ESN vs produits).
  • Comment tout cela est supporté techniquement par dynors-db et dynors-security.

Les pages de ce chapitre résument et renvoient vers : - core/ARCHITECTURE.md — vue d’ensemble modules (core, extensions, platform, internal), BOM, TAKKU - core/TAKKU_INTEGRATION_GUIDE.md — intégration dynors-db, dynors-security, génération de projets - core/packages/core/db/README.md — dynors-db (multi-tenant, stratégies, quotas) - Pour la liste complète des documents source : Documentation source (core)