ADR 0001 – Modèle générique : nœuds, aspects JSONB, liens typés

Contexte

L’outil doit gérer des notes, tâches, documents et projets avec des métadonnées cumulables (une facture est aussi un courrier lié à un projet), à la manière des aspects d’Alfresco, sans coder le domaine.

Décision

• Une table node pour tous les éléments, avec un type optionnel.
• Une ligne node_aspect par aspect porté, avec les données en jsonb et la version de la définition au moment de l’écriture.
• Une table node_link pour les relations typées (types déclarés dans config/links/), et le type wiki pour les liens libres.
• Une table node_event qui journalise toute modification (avant/après), base de l’historique des métadonnées et des règles du jalon 3.
• Les données d’aspect sont validées contre le JSON Schema de l’aspect à l’écriture, pas à la lecture.

Alternatives écartées

• Une table par aspect (colonnes typées) : exige une migration par aspect, contraire à « un aspect = un fichier ».
• EAV (entité-attribut-valeur) : requêtes et index pénibles ; JSONB + GIN couvre le besoin.
• Un seul document JSONB par nœud : rend l’ajout et le retrait d’aspect et leur versionnement moins lisibles.

Conséquences

• Les requêtes de vues se font en JSONB (->>, @>, jsonb_path_exists) ; index GIN jsonb_path_ops sur data.
• Le tri et les filtres sur un champ précis peuvent nécessiter des index d’expression ajoutés plus tard selon l’usage.
• Les champs calculés et rollups (jalon 3) seront matérialisés dans data par le moteur de règles.