Modèles de données critiques
Ce dossier documente les modèles métier principaux de DMV et de ses applications connectées.
Objectif
Stabiliser la compréhension des données avant les migrations futures, sans figer prématurément un schéma SQL détaillé.
Règles de lecture
- Les documents décrivent d’abord la logique métier.
- Les colonnes exactes ne sont pas inventées lorsqu’elles ne sont pas confirmées.
- Les éléments sont séparés entre état visible, structure probable et vision cible.
- L’IA ne doit jamais accéder directement aux tables : elle passe par l’AI Gateway et les services Laravel.
- La logique sensible doit rester contrôlée par Laravel.
Modèles couverts
- Utilisateurs, acteurs, relations acteur-utilisateur et communes.
- Publications, médias, revendications et notifications.
- Abonnements, boosts et gamification.
- Devices, campagnes et playlists PlayLoop.
Frontières métier
| Frontière | Principe |
|---|---|
| Utilisateur vs acteur | Un utilisateur est un compte ; un acteur est une entité locale publique ou organisationnelle. |
| Acteur vs commune | Une commune est un pivot territorial ; un acteur peut être rattaché à une commune. |
| DMV vs PlayLoop | PlayLoop reste autonome mais peut consommer des contenus DMV via API contrôlée. |
| IA vs data | L’IA consomme des contextes filtrés, jamais les tables directement. |
Points à clarifier globalement
- Source canonique des migrations entre Laravel et historiques Supabase.
- Noms définitifs des tables et colonnes.
- Format exact des statuts par modèle.
- Règles de rétention, archivage et audit par domaine.