# Modèle de données et cycle de vie d’un Team Module

## Document central

Le document persistant central est `teamsModules`. Côté Unity, `BackEndBrainCloud.GetTeamModule(teamUid, actModuleUid, ...)` appelle `get_document` avec l'UID généré par `UtilsBase.GetTeamModuleUid(teamUid, actModuleUid)`.

## Objets principaux

- `TeamModuleBase` : module d'une équipe;
- `TeamModuleTypeData` : données métier d'un type de module;
- `TeamModuleDecisionsData` : pages et dropdowns d'un jeu de décisions;
- `TeamModulePageData` : données persistées d'une page;
- `DataDrivenTableData`, `DataDrivenSectionData`, `DataDrivenInputData` : structure éditable;
- `ResultsByModule` : résultat/correction récupéré par le client.

```mermaid
classDiagram
class TeamModuleBase
class TeamModuleTypeData
class TeamModuleDecisionsData
class TeamModulePageData
class DataDrivenTableData
class DataDrivenSectionData
class DataDrivenInputData
TeamModuleBase --> TeamModuleTypeData
TeamModuleTypeData --> TeamModuleDecisionsData
TeamModuleDecisionsData --> TeamModulePageData
TeamModulePageData --> DataDrivenTableData
DataDrivenTableData --> DataDrivenSectionData
DataDrivenSectionData --> DataDrivenInputData

```

## Ce que TeamModuleTypeData peut porter

Selon le module, la structure contient notamment seed, bills, finished bills, pagesData, dynamicDropdownsData, comptes initiaux, inventory, immobilizations, contracts, seeded products/services, taxes, ownership et snapshots de contextes.

## Practice / Summative

Un même Team Module peut avoir plusieurs `moduleTypesData`, notamment `practice` et `summative`. La plupart des custom commands reçoivent donc systématiquement `moduleType` en plus de `teamUid` et `actModuleUid`.

## Contexts

Le framework supporte des données héritées entre contextes. Les champs `savedPagesDataByContextUids`, `initialPagesData` et les équivalents de dropdowns permettent de transporter ou préremplir l'état d'un contexte antérieur.

## Versioning

Tout changement structurel du document doit être accompagné d'une migration dans `_utils/version/version_teams_modules.js`. Ce fichier contient déjà une chaîne de migrations successives.

## Ajouter un nouveau champ TeamModuleTypeData

1. Définir si le champ est **généré**, **édité par l'étudiant**, **dérivé** ou **hérité d'un contexte précédent**.
2. Ajouter le champ côté serveur dans l'objet produit par Create Module Type Data.
3. Ajouter le champ dans le modèle Unity `TeamModuleTypeData.cs` si le client doit le lire.
4. Ajouter la désérialisation avec une valeur par défaut pour les vieux documents.
5. Si l'étudiant peut modifier le champ, ajouter une custom command dédiée ou réutiliser le système data-driven approprié.
6. Ajouter RTT si les coéquipiers doivent voir le changement immédiatement.
7. Ajouter une migration dans `version_teams_modules.js` si le champ doit exister dans les documents persistés historiques.
8. Vérifier practice et summative séparément.
9. Vérifier les backups/reopen/restart module si ce champ doit être restauré.

## Choisir où mettre une donnée

<table id="bkmrk-donn%C3%A9e-emplacement-r"><thead><tr><th>Donnée</th><th>Emplacement recommandé</th></tr></thead><tbody><tr><td>Structure immuable du module</td><td>Static data / settings.</td></tr><tr><td>Donnée générée par seed pour une équipe</td><td>`TeamModuleTypeData`.</td></tr><tr><td>Valeurs saisies dans les pages</td><td>`TeamModuleDecisionsData.pagesData`.</td></tr><tr><td>Options dynamiques de dropdown</td><td>`dynamicDropdownsData`.</td></tr><tr><td>Résultat/correction</td><td>document teams / results structures, pas dans les décisions.</td></tr><tr><td>Donnée à partager entre contextes</td><td>saved/initial context data ou champ cumulatif explicitement géré.</td></tr></tbody></table>

## Reopen / restart / backup

Une nouvelle donnée persistante doit être testée avec `restartStudentModule`, `restore_module_backup` et `reopen_module` si ces flows doivent la restaurer ou la réinitialiser. C'est un trou classique lorsqu'on ajoute seulement la génération initiale.