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.
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.