Conseils sur la conception d'applications Web ayant 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 essentielle 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 à partir de diverses sources (papier, Excel, Access, etc.) vers la base de données. Les exigences futures sont:

• Gestion du flux de travail des formulaires
• Gestion de calendrier des formulaires
• Gestion basée sur la sécurité / rôle
• Moteur de reporting
• Support mobile / tablette

Situation

Seulement 6 mois après, l'architecte / programmeur principal actuel (sous contrat) 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 pas d'objet spécifique et des 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 saturée et il existe des tâches visant uniquement à synchroniser les données, car la base de données n'est pas normalisée. Son approche a consisté à utiliser des jobs de sauvegarde pour restaurer les données manquantes et ne semble pas croire en la re-factorisation.

Ayant présenté mes conclusions au Premier ministre, l’architecte sera retiré à la fin de son contrat. On m'a confié la tâche de restructurer 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 six mois dans lequel nous pouvons nous concentrer sur la reconstruction de ce système.

J'ai suggéré d'utiliser un système de gestion de contenu tel que Drupal, mais pour des raisons de politique 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 d'une durée de vie supérieure à 40 ans. Je n'ai travaillé que sur des projets ayant une durée de vie de 3 à 5 ans. Cette situation est donc nouvelle, mais excitante.

Des questions

• Quelles considérations de conception rendront le système plus "évolutif"?
• Quelles questions faut-il poser au client / PM pour rendre le système plus "évolutif"?

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 encore opérationnelle et opérationnelle en 2053. Les technologies vont changer. Les plates-formes vont et viennent. HTML peut être une mémoire pittoresque d'ici là. Mais vos données seront toujours là.

Les données sont donc votre principal objectif. Tant que vos données sont toujours disponibles, les utilisateurs pourront s'adapter à toutes les nouvelles technologies. Assurez-vous que vos schémas de données sont bien pensés et appropriés pour une expansion. Prenez votre temps en les spécifiant.

En ce qui concerne les applications réelles, votre société a probablement raison d’avoir une directive «build from scratch». 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 de gestion de contenu en vigueur en 2003. Elles utilisent des cadres très simples développés par nos soins. Je pense que pour quelque chose comme cela, il vaut mieux un cadre très basique que vous créez spécifiquement pour les besoins du projet.

Mais la réalité est que, sur 40 ans, la société offrira (espérons-le) plusieurs services frontaux et d’arrière-plan pour s’adapter à des plates-formes en évolution. Donc, étant donné cela, je ciblerais une durée de vie de 5 à 10 ans pour des applications individuelles orientées utilisateurs.

Nous produisons des logiciels qui sont utilisés par les clients payants depuis plus de 20 ans. La base de code a survécu à plusieurs générations d'outils de contrôle de source. Notre logiciel atteint tous vos objectifs, à l'exception de la tablette.

ESIGN et UETA font partie des préoccupations . Nos avocats estiment que nous devons garder les dossiers électroniques lisibles pendant au moins 10 ans. Pour les documents qui sont conservés tout, vous devriez regarder en PDF / A .

Pour votre base de données, ne vous inquiétez pas trop de la normalisation. Au lieu de cela, vous devriez vous préoccuper de tout enregistrer et de disposer de tables d'audit qui suivent les modifications / suppressions de données. Lors de la mise à niveau des versions, prévoyez de tester les nouvelles versions en parallèle suffisamment longtemps pour garantir la migration de vos données. Ces tests de nouvelles versions incluent é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 le cas où une restauration est nécessaire. Tester les sauvegardes. Si vous envisagez de sérialiser des objets à stocker dans la base de données, utilisez 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 impossible d'un point de vue institutionnel, vous devez tout documenter dans un wiki, par exemple. Et mon conseil est un wiki qui peut être lié à votre système de suivi des bogues.

Pour votre base de code, assurez-vous d’avoir des commentaires dans votre code. La migration d'un système de contrôle de version vers un autre perdra presque toujours vos commentaires d'enregistrement. Je suis fan de nommer les tests unitaires après les numéros de spécification et de bogue. Ainsi, si le test unitaire est Test_Bug_1235 interrompu, vous savez quoi et où localiser ce qu'il est censé tester. Ce n'est pas aussi "sexy" que de nommer vos tests, Check_File_Save_Networked_Drivesmais ce type de test est difficile à revenir aux spécifications, aux exigences ou aux bogues Test_requirement_54321_case_2.

Plutôt que d'essayer de comprendre comment cette application sera toujours opérationnelle dans 20 ans, je pense que vous devriez passer six mois à résoudre les problèmes que vous avez trouvés causés par l'architecte d'origine, à mettre en place une architecture solide et robuste, et avancer à partir 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é de San Francisco, que j'ai co-écrit en 1996, est finalement devenu un paradis sur Internet il y a quelques années et qu'il n'avait jamais eu besoin d'un correctif de compatibilité de navigateur à cette époque. ; c'est presque la moitié de votre objectif de 40 ans. Et ce front-end basé sur JavaScript que j'ai créé en 1998 pour un projet du Stanford Research Institute a été remplacé par quelque chose de plus éclatant quelques années plus tard, mais rien ne s'oppose à ce que l'interface utilisateur d'origine ne puisse toujours pas fonctionner aujourd'hui avec des corrections mineures de compatibilité.

L'astuce consiste à vous assurer que votre application utilise uniquement les normes largement reconnues du W3C / ECMA et a un design épuré sous votre contrôle. Alors que de nombreuses applications Web écrites avec 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 normes principales le sont toujours. Ils peuvent sembler dépassés, mais ils fonctionnent.

L’objectif ici n’est pas d’écrire une application Web qui sera installée sur leur serveur et qui restera là pendant 40 ans sans que personne ne la touche à nouveau. Il s'agit de créer une base qui peut encore être utilisée pendant des décennies sur toute la ligne, et 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 prise 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 préfixes de fournisseur ou sans accord à 100% entre les navigateurs). Et pas de piratages de compatibilité spécifiques 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 de ES5 signifierait abandonner IE8 ou une version antérieure, ce que je suggère de toute façon, car elle nécessite des piratages spécifiques au navigateur qui seront inutiles dans quelques années. Je suggérerais le mode strict d'ES5 pour la meilleure chance de longévité, qui définit en fait la compatibilité de votre navigateur de base avec IE10 et les versions récentes de tous les autres . Ces navigateurs prennent également en charge, de manière native, de nombreuses fonctionnalités de validation de formulaire et d’espace réservé de HTML5, qui seront utiles très longtemps.

Les nouvelles éditions d’ECMAScript conservent la compatibilité avec les versions antérieures. Il sera donc beaucoup plus facile d’adopter les fonctionnalités à venir si votre code est écrit conformément aux normes en vigueur. Par exemple, les classes définies à l'aide de la classsyntaxe à venir seront totalement interchangeables avec les classes définies à l'aide de la constructor.prototypesyntaxe actuelle . Ainsi, dans cinq ans, un développeur peut réécrire les classes au format ES6 fichier par fichier sans rien casser - à supposer, bien sûr, que vous disposiez également de bons tests unitaires.

Deuxièmement, évitez les cadres d'application JavaScript à la mode, en particulier s'ils modifient la façon dont vous codez votre application. Backbone faisait fureur, puis SproutCore et Ember, 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 des modifications de code lorsque de nouvelles versions sortent et que leur longévité est discutable. J'ai récemment mis à jour une application Angular 1.1 vers la version 1.2 et il a fallu réécrire un peu. De même, passer de Backbone 2 à 3 nécessite beaucoup de modifications HTML. Les normes sont lentes pour une raison, mais ces cadres évoluent rapidement et le coût est cassé périodiquement.

De plus, les nouvelles normes officielles laissent souvent les anciens cadres obsolètes. Lorsque cela se produit, ces derniers mutent (avec des modifications radicales) ou sont laissés pour compte. Vous savez ce qu'il adviendra de toutes les bibliothèques de promesses concurrentes du monde une fois que ECMAScript 6 aura été ratifié et que tous les navigateurs prendront en charge sa classe standardisée Promise. Ils deviendront obsolètes et leurs développeurs arrêteront de les mettre à jour. Si vous avez sélectionné le bon framework, votre code pourrait s’adapter suffisamment et si vous avez mal deviné, vous envisagez une refactorisation majeure.

Donc, si vous envisagez d'adopter une bibliothèque ou un framework tiers, demandez-vous à quel point il sera difficile à supprimer à l'avenir. S'il s'agit d'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 widget de calendrier tiers que vous avez extrait avec un middleware personnalisé, son remplacement prendrait quelques heures.

Troisièmement, donnez-lui une bonne et propre structure d'application. Même si vous n'utilisez pas un cadre d'application, vous pouvez toujours tirer parti des outils de développement, des scripts de construction et d'une bonne conception. Personnellement, je suis un partisan de la gestion des dépendances de Closure Toolkit car elle est légère et que ses frais généraux sont totalement 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 facilitera beaucoup la tâche de revenir dans plusieurs années et de savoir ce que vous pensiez lorsque vous écrivez quelque chose et de ne remplacer que les parties qui en ont besoin.

Vous devez également suivre les conseils du W3C et conserver les informations de présentation en dehors de votre code HTML. (Cela inclut les astuces consistant à donner aux éléments des noms de classe de présentation, tels que "grand texte vert" et "deux colonnes"). Si votre code HTML est sémantique et que CSS est un système de présentation, il sera beaucoup plus facile à gérer et à adapter. à de nouvelles plates-formes à l'avenir. Il sera également plus facile d'ajouter un support pour les 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 depuis votre bot de construction pour chaque commit. Ceci est important pour la longévité et la fiabilité, car vous pouvez détecter les bogues plus tôt, même lorsque les navigateurs actuels les masquent. Les frameworks 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, pour 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 roi. Réfléchissez bien à votre modèle de stockage de données et assurez-vous qu'il est construit pour durer. Assurez-vous que votre schéma de données est solide et assurez-vous qu'il est également testé minutieusement à chaque commit. Et assurez-vous que votre architecture de serveur est évolutive. Ceci est encore plus important que tout ce que vous faites au début.

En laissant de côté les problèmes liés aux attentes déraisonnables de votre client et en mettant l'accent sur les problèmes de conception, je n'irais pas jusqu'à 40 ans, mais le problème que vous semblez avoir, celui d'évolutivité à long terme, est précisément ce pour quoi REST a été créé. . J'entends par là vraiment le style d'architecture REST et non le développement à la mode qui est si couramment associé au terme de nos jours.

Dans une certaine mesure, les gens se trompent sur REST parce que je n'ai pas réussi à inclure suffisamment de détails sur la conception de 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 de Wikipedia sur le sujet, qui ne repose pas sur des sources faisant autorité.

Cependant, je pense que la plupart des gens font simplement l'erreur de penser qu'il devrait être simple de concevoir des choses simples. En réalité, l'effort requis pour concevoir quelque chose est inversement proportionnel à la simplicité du résultat. En ce qui concerne les styles architecturaux, REST est très simple.

REST est une conception logicielle à l'échelle des décennies : chaque détail est destiné à promouvoir la longévité et l'évolution indépendante du logiciel.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

Vous avez mentionné votre intention d'utiliser une interface RESTful. Ce commentaire en lui-même suggère que vous devriez faire des recherches sérieuses à ce sujet et essayer de comprendre en quoi consiste vraiment le repos. Vous l'associez probablement simplement à la mise en correspondance des méthodes HTTP avec les opérations CRUD, ce que la plupart des gens pensent que REST est, mais cela n'a rien à voir avec cela.

Pensez à 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ées avec un client créé aujourd'hui. Nous avons donc quelque chose de bien dans ce département. Ce sera beaucoup de travail, je vous le garantis, car il est difficile de rester au repos, 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), je pense que je vais laisser mes deux cents aussi. 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 hobby en cours d’utilisation qui récupère des 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 vient d’ annoncer qu’il offrira ces données à un moment ou à un 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 pleinement capable de remplir sa tâche seul. Cela rend le remplacement d'une seule pièce très rapide, très sécurisé et très facile. Et quand vous devez rentrer, il n’est pas très difficile de comprendre pourquoi les choses se passent et comment vous les faites. 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.
• Procurez-vous une couche intermédiaire / couche constante solide utilisée pour la communication entre les différentes parties. Dans ce cas, j’ai utilisé JSON, mais les normes XML, ini ou similaires conviendraient également. C'est facile à répéter et peut être transformé en presque n'importe quoi. Toutes sont des normes éprouvées qui vont survivre assez longtemps. 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 à manipuler et à gérer, et est plus facilement échangeable.
• Ne vous inquiétez pas des décisions du langage de programmation. Ceux-ci changeront avec le temps. Assurez-vous simplement que vous utilisez la langue avec laquelle vous êtes à l'aise 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, il s'agit d'URI) où les mini-applications sont appelées et / ou échangent des données.

Résumé: Ce qui me préoccupe le plus, c’est la séparation des problèmes et la capacité d’échange des pièces affectées à des tâches. Vous savez simplement que dans 40 ans (même dans 5 ou 10) le matériel, les interfaces, le stockage, etc. vont beaucoup changer. Et les développeurs ultérieurs devront réagir à ces modifications et échanger des éléments de votre application, qu’il s’agisse du conteneur de données ou de l’interface utilisateur.

Pour que les choses soient aussi "à l'épreuve du temps" que possible, planifiez le changement. C’est-à-dire que vous essayez de ne pas optimiser pour autre chose que la capacité de changer facilement. Donc, pas de normalisation, pas de validation stricte et couplage lâche.

• Utilisez les principales technologies open source. Pour les données, les systèmes à source fermée constituent une source de risque majeure, car il est impossible de prévoir les entreprises qui vont faire faillite ou de changer de stratégie, ce qui implique un accès complet 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. Les sortes de données non structurées utilisées sont presque directement extraites du manuel pour un magasin de documents comme MongoDB. Les bases de données relationnelles traditionnelles et leur normalisation sont utiles lorsque vous savez comment vos données seront structurées, mais c'est vraiment une fiction, surtout ici. Les coûts liés à la modification du schéma dans une base de données RDBS ne cessent d'augmenter à 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. Casser tous les accès aux données et les transformer en services Web est un pas dans cette direction. En combinant cela avec les files de messages pour soumettre les modifications, cela aidera différentes parties du système à changer de langue ou de technologie au fil du temps.

OK, je vais donc dire quelques choses 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 dirigez le projet, vous devez prendre du recul et réfléchir aux chances de succès de ce projet. . Parce qu'ils sont pratiquement à zéro.

Vous devez consacrer énormément de temps à la conception de la base de données et à sa mise au point. Pour que ce projet réussisse, vous devez faire appel à un architecte de données, et le plus tôt possible. Sans une personne expérimentée 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.

S'attendre à ce que deux personnes (dont l'une porte le titre de jr. Dev) construise quelque chose à partir de zéro, qui devrait durer 40 ans, ne réussira probablement pas. Il devrait y avoir une équipe composée de nombreuses personnes expérimentées dans de grands projets comme celui-ci, qui travaillent à la conception des données, à la conception de l'API et à la conception de l'application. Quelque chose comme ce n'est pas un projet de 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 à tout ce qui pourrait ne plus être à la mode en quelques années seulement. Si vous le faisiez, trouver quelqu'un dans le système dans 5 à 10 ans pourrait devenir très difficile très rapidement.

Je transmettrais ce conseil à la direction et lui expliquerais qu'il est nécessaire de faire participer davantage de personnes de haut rang au projet. Sinon, le projet est voué à l'échec et vous finirez probablement par en être le responsable.

L'application n'a pas besoin de survivre 40 ans sans aucune évolution. Mais, comme il devrait ou devrait être construit à partir de rien, il pourrait toujours fonctionner.

Ce qui est le plus important, c’est l’architecture des données qui permet une certaine stabilité et une bonne gouvernance, tout en étant extensible.

Nous avons conçu une architecture de données et une taxonomie qui pourraient presque survivre à la fin de l'humanité, tout en restant extensibles. Vous devez trouver un véritable responsable de l’architecture des données et de la fiscalité des données pour le faire à votre place.

La clé ici est de se concentrer sur la base de données (comme plusieurs l'ont dit plus haut). Cela doit être cohérent et décrire complètement l'opération. Il doit évoluer avec les opérations à mesure qu’elles évoluent. Si ce n'est pas facile de changer, alors ça va devenir obsolète et c'est le baiser de la mort. Le reste est relativement moins important.

Je suis en désaccord avec ceux qui sont mentionnés ci-dessus et qui suggèrent que la normalisation n'est pas importante, même s'il existe 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 effectivement ignorer le problème jusqu'à ce que vous puissiez le résoudre.

La société pour laquelle je travaillais avant ma retraite utilise un système écrit à partir de rien et qui connaît une croissance presque continue depuis 25 ans et couvre pratiquement tous les aspects d’un détaillant de taille moyenne. Les aspects de ce système qui me semblent importants sont les suivants:

• 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. Par conséquent, une insistance presque paranoïaque sur les noms est nécessaire. Nous avons des tables de mnémoniques définies qui sont ensuite combinées pour constituer des noms de table et de champ et tous les «codes» ont également été nommés en tant que constantes et stockés dans une structure de table EAV.
• Nous avons encapsulé la logique métier dans des déclencheurs de base de données. Cela est pénible au début et nécessite un travail supplémentaire pour transmettre des messages d'erreur aux clients et pour permettre de modifier les déclencheurs de manière flexible sans verrouiller l'ensemble de la table 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 que sinon.
• Supposons que vous conserviez au moins les tables de références (idéalement toutes les transactions les plus rapides et les moins importantes) pendant toute la durée de vie du système, même lorsqu'elles sont «supprimées» pour que vos références soient correctes.
• En raison de ce qui précède, assurez-vous que les identifiants uniques et les numéros de transaction sont dimensionnés à long terme. (Au départ, j’ai suggéré en plaisantant qu’ils devaient durer jusqu’à ma retraite).

Je suggérerais d'utiliser la source d'événements et la 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 venir. Donc, même si vous placez de lourdes pensées sur un modèle, il est certain que celui-ci sera dépassé. La migration de toutes les données avec chaque version pourrait ne pas être réalisable. Le mieux est donc d’avoir un modèle qui réponde à vos besoins actuels et qui est calculé à partir d’événements déjà enregistrés chaque fois que vous en avez besoin, puis de transmettre des événements calculés à partir de l’état actuel de ce modèle.

Ayez également des tests en tête. Si l'application est utilisée dans dix ans, les testeurs doivent s'assurer qu'elle continue de faire ce qu'elle est censée faire. Faites en sorte que le test d'intégration de votre application soit aussi simple que possible.