ADR-001 : Cycle de vie explicite des candidatures
Statut
Acceptée
Contexte
Balyze est centré sur le suivi des candidatures dans le temps. Dès les premières étapes du projet, le besoin s’est imposé de définir clairement la manière dont une candidature évolue, de sa création à sa finalisation.
Sans cycle de vie explicite, les candidatures risquent de devenir des objets ambigus :
- partiellement soumises
- éditables de manière incohérente
- difficiles à analyser d’un point de vue historique
Un cycle de vie clair est nécessaire afin de :
- préserver l’exactitude historique
- appliquer des règles métier cohérentes
- éviter une gestion implicite ou dispersée des états
Décision
Un cycle de vie explicite et fini est défini pour l’entité métier Application.
Ce cycle de vie est représenté par une énumération dédiée et appliqué via des services métier.
Les états suivants sont définis :
draftsubmittedin_progressrejectedaccepted
Les transitions d’état sont explicites, unidirectionnelles et contrôlées.
Une fois qu’une candidature est soumise :
- les données structurelles sont figées
- les données contextuelles restent éditables
- le timestamp de soumission est défini et devient immuable
Le retour à un état précédent (par exemple revenir à draft) n’est pas autorisé.
Justification
Cette décision privilégie la clarté et la prévisibilité plutôt qu’une flexibilité maximale.
Principaux éléments pris en compte :
- une candidature soumise représente une intention à un instant donné
- les données historiques ne doivent pas être modifiées rétroactivement
- une gestion implicite des états augmente la complexité à long terme
- des transitions explicites facilitent le raisonnement, les tests et la maintenance
En contraignant le cycle de vie dès le départ, les évolutions futures peuvent être ajoutées en toute sécurité sans remettre en cause les hypothèses existantes.
Alternatives envisagées
Cycle de vie implicite (statut comme simple indicateur)
Rejetée car :
- les règles deviennent dispersées dans le code
- les contraintes d’éditabilité sont plus difficiles à appliquer
- l’état des candidatures devient ambigu avec le temps
Autoriser un retour à l’état draft
Rejetée car :
- cela casse la cohérence historique
- cela complique les règles d’éditabilité
- cela introduit des cas limites liés aux timestamps et aux documents
Transitions automatiques ou basées sur le temps
Reportée. Le périmètre actuel ne justifie pas la complexité supplémentaire induite.
Conséquences
Positives
- frontières métier claires
- application cohérente des règles
- services et policies plus simples
- maintenabilité améliorée sur le long terme
Compromis
- flexibilité réduite pour certains cas limites
- toute évolution du cycle de vie nécessite une décision explicite
Ces compromis sont jugés acceptables au stade actuel du projet.
Documentation associée
- Vue d’ensemble du domaine
- Cycle de vie d’une candidature
- Règles d’éditabilité d’une candidature