Données & reprise · MCD · svc-notifications
svc-notifications — modèle de données minimal
Schéma créé vide : configuration seule. Un manque à combler tout de même — les jetons push que l'architecture loge ici (c'est ce qui justifie que mobile-bff soit sans base) n'ont aucune table.
3tables du noyau
2compléments
1manquantes
0ligne reprise
MCD minimal
Contenu minimal en tables
Le noyau est ce sans quoi le service ne peut pas tenir ses agrégats ni sa première tranche fonctionnelle. Les tables du socle technique s'ajoutent à cette liste et ne sont pas répétées.
| Niveau | Table | Contenu et point de vigilance |
|---|---|---|
| NOYAU | notification_templates | Modèles par canal et par langue. |
| NOYAU | dispatches | Envois : destinataire, canal, statut, erreurs, rejeux. |
| NOYAU | notification_preferences | Préférences par usager et par canal. |
| MANQUE | device_push_tokens | Manquante. L'architecture place les jetons push ici — c'est ce qui justifie que mobile-bff soit sans base. Aucune table ne les porte aujourd'hui. |
| COMPL. | notification_routing_rules | Routage événement → canal, priorité, filtres. |
| COMPL. | notification_attachment_links | Pièces jointes : références vers svc-documents. |
| PROJ. | known_users | Projection de l'usager (identité maîtrisée par Keycloak). |
Sources legacy et transformations
Aucune source legacy : ce schéma démarre vide ou est initialisé par paramétrage.
Points de vigilance
device_push_tokens conditionne la règle « mobile-bff sans base ». Les jetons push sont le seul état que le BFF mobile pourrait avoir besoin de persister ; l'architecture a choisi de le loger ici. Tant que la table n'existe pas, ce état n'a pas de propriétaire désigné.
Décisions attendues
- Ajouter device_push_tokens au schéma — c'est ce qui donne un propriétaire aux jetons push et permet à mobile-bff de rester sans état.