Conseils sur la conception d'applications Web avec une durée de vie de plus de 40 ans
Scénario
Actuellement, je fais partie d'un projet de soins de santé dont la principale exigence est de capturer des données avec des attributs inconnus à l'aide de formulaires générés par les utilisateurs par les fournisseurs de soins de santé. La deuxième exigence est que l'intégrité des données est la clé et que l'application sera utilisée pendant plus de 40 ans. Nous migrons actuellement les données du client des 40 dernières années depuis diverses sources (Paper, Excel, Access, etc ...) vers la base de données. Les exigences futures sont les suivantes:
- Gestion du workflow des formulaires
- Gestion du planning des formulaires
- Sécurité/gestion basée sur les rôles
- Moteur de rapports
- Prise en charge mobile/tablette
Situation
Seulement 6 mois plus tard, l'architecte/programmeur principal (sous contrat) actuel a adopté l'approche "rapide" et a conçu un système médiocre. La base de données n'est pas normalisée, le code est couplé, les niveaux n'ont aucun objectif dédié et les données commencent à disparaître car il a conçu des beans pour effectuer des "suppressions" sur la base de données. La base de code est extrêmement gonflée et il y a des tâches juste pour synchroniser les données car la base de données n'est pas normalisée. Son approche a consisté à s'appuyer sur des travaux de sauvegarde pour restaurer les données manquantes et ne semble pas croire à la refactorisation.
Après avoir présenté mes conclusions au PM, l'architecte sera démis de ses fonctions à la fin de son contrat. On m'a confié la tâche de reconcevoir cette application. Mon équipe est composée de moi et d'un programmeur junior. Nous n'avons pas d'autres ressources. Nous avons obtenu un gel des exigences de 6 mois au cours duquel nous pouvons nous concentrer sur la reconstruction de ce système.
J'ai suggéré d'utiliser un système CMS comme Drupal, mais pour des raisons de politique au sein de l'organisation du client, le système doit être construit à partir de zéro.
C'est la première fois que je conçois un système avec une durée de vie de plus de 40 ans. Je n'ai travaillé que sur des projets d'une durée de vie de 3 à 5 ans, donc cette situation est très nouvelle, mais passionnante.
Questions
- Quelles considérations de conception rendront le système plus "à l'épreuve du temps"?
- Quelles questions faut-il poser au client/PM pour rendre le système plus "pérenne"?
Les données sont roi
Je pense qu'il est un peu déraisonnable de s'attendre à ce qu'une application Web vers 2013 soit toujours opérationnelle et exécutable en 2053. Les technologies vont changer. Les plateformes vont et viennent. Le HTML peut être une mémoire pittoresque d'ici là. Mais vos données seront toujours là.
Les données sont donc votre objectif principal. Tant que vos données sont toujours là, les gens pourront s'adapter aux nouvelles technologies. Assurez-vous que vos schémas de données sont bien pensés et bien adaptés à l'expansion. Prenez votre temps pour les préciser.
En ce qui concerne les applications réelles, votre entreprise a probablement raison d'avoir une directive "construire à partir de zéro". Je gère quelques applications Web de plus de 10 ans, et je suis très heureux qu'elles ne soient pas enfermées dans les systèmes CMS en vigueur en 2003. Ils utilisent des frameworks très simples et développés à la maison. Je pense que pour quelque chose comme ça, vous êtes mieux avec un cadre très basique que vous créez spécialement pour les besoins du projet.
Mais la réalité est que, sur 40 ans, la société fournira (espérons-le) pas mal de services front-end et back-end pour s'adapter aux plates-formes en évolution. Donc, étant donné cela, je viserais une durée de vie de 5 à 10 ans pour les applications individuelles destinées aux utilisateurs.
Nous produisons des logiciels qui sont utilisés par des clients payants depuis plus de 20 ans. La base de code a survécu à plusieurs générations d'outils de contrôle de code source. Notre logiciel frappe tous vos points de balle, sauf pour la tablette.
Certaines des préoccupations incluent ESIGN et UETA . Nos avocats estiment que nous devons garder les dossiers électroniques lisibles pendant au moins 10 ans. Pour les documents qui sont conservés en entier, vous devriez regarder PDF/A .
Pour votre base de données, ne vous inquiétez pas trop de la normalisation. Au lieu de cela, vous devriez vous soucier de tout consigner et d'avoir des tables d'audit qui suivent les modifications/suppressions dans les données. Lors de la mise à niveau des versions, prévoyez de tester les nouvelles versions en parallèle pendant suffisamment de temps pour vous assurer que vos données ont été migrées. Ce test de nouvelles versions inclut également de nouveaux systèmes d'exploitation - nous avons eu de très mauvaises surprises au fil des ans. Conservez le support d'installation et les clés de licence dans l'éventualité d'une restauration. Testez les sauvegardes. Si vous allez sérialiser des objets à stocker dans la base de données, faites-le en XML au lieu de la sérialisation fournie par votre infrastructure de développement.
Pour votre personnel, les bases de code à long terme nécessitent une mémoire à long terme. Idéalement, vous voudriez des gens qui existent depuis longtemps. Si cela est institutionnellement impossible, vous devez tout documenter dans quelque chose comme un wiki. Et mon conseil est un wiki qui peut être lié à votre système de suivi des bogues.
Pour votre base de code, assurez-vous que vous avez des commentaires dans votre code. La migration d'un système de contrôle de version à un autre perdra presque toujours vos commentaires d'enregistrement. Je suis un fan des noms de tests unitaires d'après les spécifications et les numéros de bogues. De cette façon, si le test unitaire Test_Bug_1235 se casse, alors vous savez quoi et où retrouver ce qu'il est censé tester. Ce n'est pas aussi "sexy" que de nommer vos tests Check_File_Save_Networked_Drives mais ce genre de test est difficile à revenir aux spécifications, exigences ou bogues contrairement à Test_requirement_54321_case_2.
Plutôt que d'essayer de comprendre comment cette application va encore fonctionner dans 20 ans, je pense que vous devriez passer vos six mois à résoudre les problèmes que vous avez constatés que l'architecte d'origine a causés, à mettre en place une architecture sensible et robuste, et avancer de là.
La dénormalisation partielle d'une base de données n'est pas nécessairement totalement inattendue dans un contexte médical. Certaines parties des bases de données médicales ont des caractéristiques qui les rendent bien adaptées au modèle EAV (Entity/Attribute/Value) .
Réponse d'un point de vue frontal:
N'écoutez pas tout le monde en disant que cela ne peut pas être fait, car un service Web expérimental de l'Université d'État de San Francisco que j'ai co-écrit en 1996 est finalement allé au paradis Internet il y a quelques années, et n'a jamais eu besoin d'un seul correctif de compatibilité du navigateur à cette époque ; c'est presque la moitié de votre objectif de 40 ans. Et ce front-end basé sur JavaScript J'ai fait en 1998 pour un projet du Stanford Research Institute a été remplacé par quelque chose de plus flash quelques années plus tard, mais il n'y a aucune raison que l'interface utilisateur d'origine ne puisse pas encore fonctionner aujourd'hui avec corrections de compatibilité mineures.
L'astuce consiste à s'assurer que votre application utilise uniquement les normes W3C/ECMA largement prises en charge et a une conception épurée sous votre contrôle. Alors que de nombreuses applications Web écrites sur la technologie à la mode des années 90 ne fonctionnent pas bien ou pas du tout aujourd'hui, les applications Web des années 90 écrites selon les principales normes fonctionnent toujours. Ils peuvent sembler dépassés, mais ils fonctionnent.
Le but ici n'est pas d'écrire une application web qui va monter sur leur serveur et y rester pendant 40 ans sans que personne ne la touche à nouveau. Il s'agit de construire une fondation qui peut encore être utilisée des décennies plus tard, qui peut évoluer pour prendre en charge de nouvelles fonctionnalités sans avoir à être reconstruite à partir de zéro.
Tout d'abord, vous devez coder selon les normes officielles et uniquement selon les normes officielles. Aucune fonctionnalité JavaScript ne fait partie d'une norme ECMAScript ratifiée; ES5.1 est la version actuelle et est généralement pris en charge, ce qui permet de cibler en toute sécurité. De même, les versions actuelles de HTML5, CSS et Unicode sont bonnes. Pas de fonctionnalités expérimentales JavaScript, CSS3 ou HTML (celles avec des préfixes de fournisseurs ou sans accord à 100% entre les navigateurs). Et pas de piratage de compatibilité spécifique au navigateur. Vous pouvez commencer à utiliser une nouvelle fonctionnalité une fois qu'elle est dans la norme et que tout le monde la prend en charge sans préfixe.
La prise en charge d'ES5 signifierait la suppression d'IE8 ou d'une version antérieure, ce que je suggère de toute façon, car elle nécessite des hacks spécifiques au navigateur qui seront inutiles dans quelques années. Je suggérerais le mode strict d'ES5 pour les meilleures chances de longévité, ce qui définit en fait la compatibilité de votre navigateur de base à IE10 et versions récentes de tout le monde . Ces navigateurs prennent également en charge nativement de nombreuses fonctionnalités de validation de formulaire et d'espace réservé de HTML5, qui seront utiles pendant très longtemps.
Les nouvelles éditions d'ECMAScript maintiennent la compatibilité avec les anciennes versions, il sera donc beaucoup plus facile d'adopter les fonctionnalités à venir si votre code est écrit selon les normes actuelles. Par exemple, les classes définies à l'aide de la prochaine syntaxe class seront entièrement interchangeables avec les classes définies avec la syntaxe actuelle constructor.prototype. Ainsi, en cinq ans, un développeur peut réécrire les classes au format ES6 fichier par fichier sans casser quoi que ce soit - en supposant, bien sûr, que vous avez également de bons tests unitaires.
Deuxièmement, évitez les cadres d'applications JavaScript à la mode, surtout s'ils changent la façon dont vous codez votre application. Backbone était à la mode, puis SproutCore et Ember l'étaient, et maintenant Angular est le cadre que tout le monde aime promouvoir. Ils peuvent être utiles, mais ils ont aussi quelque chose en commun: ils cassent souvent des applications et nécessitent le code change lorsque de nouvelles versions sortent et que leur longévité est discutable. J'ai récemment mis à jour une application Angular 1.1 en 1.2, et il a fallu en réécrire un peu. De même, passer de Backbone 2 à 3 nécessite beaucoup de changements HTML. Les normes évoluent lentement pour une raison, mais ces cadres évoluent rapidement et les choses qui se cassent périodiquement sont le coût.
De plus, les nouvelles normes officielles laissent souvent les anciens cadres obsolètes, et lorsque cela se produit, ces cadres mutent (avec des changements de rupture) ou sont laissés pour compte. Vous savez ce qui va arriver à toutes les bibliothèques de promesses concurrentes du monde une fois ECMAScript 6 ratifié et tous les navigateurs prendront en charge sa classe Promise standardisée? Ils deviendront obsolètes et leurs développeurs cesseront de les mettre à jour. Si vous avez choisi le bon framework, votre code pourrait s'adapter assez bien, et si vous avez mal deviné, vous envisagerez une refactorisation majeure.
Donc, si vous envisagez d'adopter une bibliothèque ou un framework tiers, demandez-vous combien il sera difficile de supprimer à l'avenir. Si c'est un framework comme Angular qui ne peut jamais être supprimé sans reconstruire votre application à partir de zéro, c'est un bon signe qu'il ne peut pas être utilisé dans une architecture de 40 ans. S'il s'agit d'un troisième - widget de calendrier de partie que vous avez extrait avec un middleware personnalisé, le remplacer prendrait quelques heures.
Troisièmement, donnez-lui une bonne structure d'application propre. Même si vous n'utilisez pas de framework d'application, vous pouvez toujours profiter des outils de développement, créer des scripts et un bon design épuré. Je suis personnellement un fan de la gestion des dépendances de Closure Toolkit car il est léger et ses frais généraux sont complètement supprimés lors de la création de votre application. LessCSS et SCSS sont également d'excellents outils pour organiser vos feuilles de style et créer des feuilles de style CSS basées sur des normes pour la publication.
Vous pouvez également organiser votre propre code en classes à usage unique avec une structure MVC. Cela rendra beaucoup plus facile de revenir plusieurs années dans le futur et de savoir ce que vous pensiez lorsque vous avez écrit quelque chose, et de remplacer uniquement les parties qui en ont besoin.
Vous devez également suivre les conseils du W3C et garder les informations de présentation complètement hors de votre HTML. (Cela inclut des astuces comme donner des noms de classe de présentation d'éléments, comme "big-green-text" et "two-column-wide".) Si votre HTML est sémantique et CSS est de présentation, il sera beaucoup plus facile de le maintenir et de l'adapter vers de nouvelles plateformes à l'avenir. Il sera également plus facile d'ajouter la prise en charge de navigateurs spécialisés pour les personnes aveugles ou handicapées.
Quatrièmement, automatisez vos tests et assurez-vous d'avoir une couverture presque complète. Écrivez des tests unitaires pour chaque classe, côté serveur ou en JavaScript. Sur le front-end, assurez-vous que chaque classe fonctionne conformément à ses spécifications dans chaque navigateur pris en charge. Automatisez ces tests à partir de votre bot de build pour chaque commit. Ceci est important pour la longévité et la fiabilité, car vous pouvez détecter les bogues tôt, même lorsque les navigateurs actuels les obscurcissent. Les cadres de test basés sur JSUnit de Jasmine et de Google Closure sont bons.
Vous voudrez également exécuter des tests fonctionnels complets de l'interface utilisateur, dans lesquels Selenium/WebDriver sont bons. Fondamentalement, vous écrivez un programme qui parcourt votre interface utilisateur et l'utilise comme si une personne le testait. Câblez-les également au bot de construction.
Enfin, comme d'autres l'ont mentionné, vos données sont capitales. Réfléchissez à votre modèle de stockage de données et assurez-vous qu'il est conçu pour durer. Assurez-vous que votre schéma de données est solide et assurez-vous qu'il est également testé de manière approfondie à chaque validation. Et assurez-vous que l'architecture de votre serveur est évolutive. C'est encore plus important que tout ce que vous faites sur le front-end.
Laissant de côté les questions des attentes déraisonnables de votre client et se concentrant sur les problèmes de conception, je n'irais pas jusqu'à 40 ans, mais le problème que vous semblez avoir, de l'évolutivité à long terme, est précisément ce qui REST a été créé pour. Par cela, je veux vraiment dire REST en tant que style d'architecture, pas le développement piloté par les mots à la mode qui est si communément associé au terme de nos jours).
Dans une certaine mesure, les gens se trompent REST parce que je n'ai pas inclus suffisamment de détails sur la conception du type de média dans ma thèse. C'est parce que j'ai manqué de temps, pas parce que je pensais que c'était moins important que les autres aspects de REST. De même, je soupçonne que beaucoup de gens se trompent parce qu'ils ne lisent que l'entrée Wikipedia sur le sujet, qui n'est pas basée sur des sources faisant autorité.
Cependant, je pense que la plupart des gens font simplement l'erreur de concevoir des choses simples. En réalité, l'effort requis pour concevoir quelque chose est inversement proportionnel à la simplicité du résultat. Au fur et à mesure des styles architecturaux, REST est très simple.
REST est une conception logicielle à l'échelle des décennies : chaque détail est destiné à favoriser la longévité du logiciel et son évolution indépendante.
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724
Vous avez mentionné que vous envisagez d'utiliser une interface RESTful. Ce commentaire en soi suggère que vous devriez faire des recherches sérieuses à ce sujet et essayer de comprendre de quoi s'agit vraiment REST. Vous l'associez probablement simplement au mappage des méthodes HTTP aux opérations CRUD que la plupart des les gens pensent que REST l'est, mais cela n'a rien à voir avec cela.
Considérez REST comme une formalisation de l'architecture du Web lui-même. D'une manière ou d'une autre, de nombreuses parties du Web écrites il y a une décennie ou plus sont encore disponibles et peuvent être utilisé avec un client fait aujourd'hui, donc nous avons quelque chose de bien dans ce département. Ce sera beaucoup de travail, je vous le garantis, parce que faire REST bien est difficile, mais les avantages à long terme en valent la peine.
Après avoir lu la question et les autres réponses (très bien pensées), j'ai pensé que je laisserais aussi mes deux cents. Remarque: Je n'ai pas du tout besoin de maintenir une application/un logiciel vraiment ancien. Ce que j'utilise comme référence est ma propre application Web de loisirs en cours qui récupère certaines données gouvernementales ouvertes, les analyse et les affiche dans différents formats. L'application a commencé comme un projet où je n'étais pas seul et où le gouvernement a juste annoncé qu'il offrirait ces données quand, d'une manière ou d'une autre. Il était donc clair que beaucoup de choses changeront avec le temps. Et ils l'ont fait. Ce que j'en ai appris:
- Divisez les choses en mini-applications. Chacun est en mesure de remplir sa tâche de manière autonome. Cela rend le remplacement d'une seule pièce très rapide, très sûr et très facile. Et quand vous devez rentrer, ce n'est pas vraiment difficile de savoir pourquoi les choses se produisent et comment elles se produisent. Si vous ou quelqu'un d'autre devez changer quelque chose plus tard, il est plus facile de remplacer une seule pièce qu'un ensemble de choses.
- Obtenez un middleware/-layer constant solide qui est utilisé pour la communication entre les différentes parties. Dans ce cas, j'ai utilisé JSON, mais XML, ini ou des normes similaires conviendraient également. Il est facile à répéter et peut être transformé en presque n'importe quoi. Tous sont des normes éprouvées qui survivront un certain temps. Même si les données sous-jacentes et/ou le modèle de stockage vont changer. Chacune des applications peut utiliser son propre stockage de données pour sa tâche spécifique. Cela réduit la quantité de données numérisées pour une tâche, donc plus facile à gérer et à entretenir et est plus facilement échangeable.
- Ne vous inquiétez pas des décisions de langage de programmation. Celles-ci changeront avec le temps. Assurez-vous simplement d'utiliser la langue qui vous convient ou qui convient le mieux à une tâche.
- Assurez-vous que votre stockage de données est "évolutif horizontalement" et qu'il est facile de brancher des modules de stockage supplémentaires.
- Obtenez un point commun (dans mon cas, ce sont les URI) où les mini-applications sont appelées et/ou échangent des données.
En résumé: la chose qui me tient le plus à cœur est la séparation des préoccupations et la capacité d'échange des pièces affectées aux tâches. Vous savez simplement que dans 40 ans (même dans 5 ou 10 ans) le matériel, les interfaces, le stockage, etc. changeront beaucoup. Et les développeurs ultérieurs devront réagir à ces changements et échanger des parties de votre application, que ce soit le conteneur de données ou des parties de l'interface utilisateur.
Pour rendre les choses aussi "pérennes" que possible, planifiez le changement. Autrement dit, faites de votre mieux pour ne pas optimiser pour autre chose que la capacité de changer facilement. Donc pas de normalisation, pas de validation stricte et un couplage lâche à gogo.
Utilisez les principales technologies open source. Pour les données, les systèmes à source fermée sont une source de risque majeure, car on ne peut pas prévoir quelles entreprises seront soumises ou changeront de stratégie, emportant avec elles tout accès aux données. En outre, les projets open source mineurs sans communauté dynamique sont également plus susceptibles de perdre leur soutien.
Utilisez une base de données NoSQL sans schéma. Le type de données non structurées utilisées est presque directement sorti du manuel d'un magasin de documents comme MongoDB. Les bases de données relationnelles traditionnelles et leur normalisation sont bonnes lorsque vous savez comment vos données vont être structurées, mais c'est vraiment une fiction, surtout ici. Les coûts de changement de schéma dans un RDBS deviennent de plus en plus importants à mesure que le système se développe. Sachez que quelle que soit la structure choisie, elle finira par changer.
Découplez fortement le système en utilisant des normes largement acceptées. La division de tous les accès aux données et de la mutation en services Web est un pas dans cette direction. Combiner cela avec des files d'attente de messages pour soumettre des modifications et autres aidera les parties individuelles du système à changer de langue ou de technologie au fil du temps.
OK, donc je vais dire des choses ici qui vont probablement être assez impopulaires, mais restez avec moi ici.
Comme il s'agit de votre premier projet où les données et/ou l'application sont censées durer plus de 20 ans, et que vous êtes le leader du projet, vous devez prendre du recul et réfléchir aux chances de réussite de ce projet. . Parce qu'ils sont fondamentalement proches de zéro.
Vous devez passer énormément de temps à vous concentrer sur la conception de la base de données et à bien faire les choses. Pour que ce projet réussisse, vous devez faire appel à un architecte de données dans le projet, et le plus tôt possible. Sans quelqu'un qui est expérimenté dans la conception de bases de données et qui a l'habitude de voir comment les données pourront être utilisées à l'avenir, les chances que les données soient toujours utiles après 5 ans et encore moins 40 ans sont minces.
Attendre que deux personnes (dont l'une a le titre de junior dev) pour construire quelque chose à partir de zéro, qui devrait durer 40 ans, ne va probablement pas réussir. Il devrait y avoir une équipe de personnes dont beaucoup sont expérimentées dans le travail avec de grands projets comme celui-ci et qui travaillent sur la conception des données, la conception des API et la conception des applications. Quelque chose comme ça n'est pas un projet pour 2 personnes.
Vouloir lier le projet à quelque chose comme Drupal montre pourquoi le projet a besoin de personnes habituées à travailler sur ce type de projets. Vous ne voulez pas lier l'application à quoi que ce soit qui pourrait sortir de style en quelques années. Si vous le faisiez, trouver quelqu'un pour travailler sur le système dans 5 à 10 ans pourrait devenir très difficile très rapidement.
Je voudrais transmettre ces conseils à la direction et leur expliquer que vous devez recruter davantage de cadres supérieurs sur le projet. Sinon, le projet est voué à l'échec, et vous finirez probablement par être le coupable.
L'application n'a pas besoin de survivre 40 ans sans aucune évolution. Mais, parce qu'il serait ou devrait être construit à partir de zéro, il pourrait encore "fonctionner".
Ce qui est le plus important, c'est "l'architecture des données" qui permet une certaine stabilité et gouvernance ainsi qu'extensible.
Nous avons conçu une architecture de données et une taxonomie qui pourraient presque survivre à la fin de l'humanité tout en étant extensibles. Vous devez trouver une véritable personne en TAXONOMIE DES DONNÉES/ARCHITECTURE DES DONNÉES pour le faire pour vous.
La clé ici est de se concentrer sur la base de données (comme plusieurs l'ont dit ci-dessus). Cela doit être cohérent et décrire complètement l'opération. Il doit grandir avec l'opération à mesure qu'elle évolue. S'il n'est pas facile de changer, il sera périmé et c'est le baiser de la mort. Le reste est relativement moins important.
Je ne suis pas d'accord avec ceux ci-dessus qui suggèrent que la normalisation n'est pas importante, bien qu'il y ait toujours des cas où les systèmes actuels ne sont pas à la hauteur. Dans ces cas, dénormalisez mais assurez-vous que la base de données gère les écritures/modifications supplémentaires dans le cadre d'une transaction atomique. De cette façon, vous pouvez ignorer efficacement le problème jusqu'à ce que vous puissiez le résoudre.
L'entreprise pour laquelle je travaillais avant la retraite gère un système qui a été écrit à partir de zéro et qui a connu une croissance presque continue pendant 25 ans et couvre pratiquement tous les aspects d'un détaillant moyen. Les aspects de ce système qui me semblent importants sont:
- L'intégration est vitale.
- La base de données doit être aussi correcte et compréhensible à la fois pour le personnel informatique et les autres membres du personnel, donc un accent presque paranoïaque sur la dénomination est nécessaire. Nous avons des tables de mnémoniques définies qui sont ensuite combinées pour former des noms de table et de champ et tous les "codes" ont également été nommés comme constantes et stockés dans une structure de table EAV.
- Nous avons encapsulé la logique métier dans les déclencheurs de base de données. Cela est douloureux au début et nécessite un travail supplémentaire pour transmettre des messages d'erreur aux clients et pour permettre aux déclencheurs d'être modifiés de manière flexible sans verrouiller la table entière sur certains systèmes, mais cela devient rapidement un gain de temps considérable et oblige la base de données à être beaucoup plus correcte qu'autrement.
- Supposons que vous conserviez au moins des tables de référence (idéalement toutes les transactions sauf les plus rapides et les moins importantes) pendant toute la durée de vie du système, même lorsqu'elles sont "supprimées", vos références sont donc correctes.
- En raison de ce qui précède, assurez-vous que tous les identifiants et numéros de transaction uniques sont dimensionnés à long terme. (J'ai d'abord suggéré en plaisantant qu'ils devaient durer jusqu'à ma retraite).
Je suggère d'utiliser sourcing d'événements et séparation des responsabilités de commande et de requête . C'est principalement parce que la seule chose dont vous pouvez être sûr, ce sont les événements qui sont déjà apparus. De nouveaux types d'événements pourraient arriver. Donc, même si vous réfléchissez beaucoup à un modèle, il est certain que cela deviendra obsolète. La migration de toutes les données avec chaque version peut ne pas être possible. Donc, le mieux est d'avoir un modèle qui correspond à vos besoins actuels et qui est calculé à partir d'événements déjà enregistrés chaque fois que vous en avez besoin, puis de distribuer des événements qui sont calculés à partir de l'état actuel de ce modèle.
Ayez également à l'esprit les tests. Si l'application est utilisée dans dix ans, les testeurs doivent s'assurer qu'elle fait toujours ce qu'elle est censée faire. Rendez donc l'intégration des tests de votre application aussi simple que possible.