Lisez la première partie.
Fonctionnalités de l'implémentation de Event Sourcing
D'un point de vue technique, Event Sourcing ne nécessite qu'une implémentation de journalisation des événements et de lecture du journal.
Dans le cas le plus simple, un fichier peut être utilisé comme stockage d'événements, dans lequel un événement distinct est enregistré sur chaque ligne, ou plusieurs fichiers, lorsque chaque événement est enregistré dans un fichier séparé. Mais en règle générale, dans les grands systèmes exigeant le parallélisme et l'évolutivité, des méthodes de stockage plus fiables sont utilisées.
Le journal des événements est un modèle très courant utilisé en conjonction avec le courtier de messages (middleware orienté message) et les systèmes de traitement de flux d'événements. Un courtier de messages, utilisé comme journal des événements, peut stocker l'intégralité de l'historique des messages si nécessaire.
Les modèles relationnels et documentaires se concentrent généralement sur la modélisation d'entités. Dans de tels modèles, l'état actuel est facile à obtenir en lisant une ou plusieurs lignes ou documents. Il convient de noter que l'approvisionnement en événements et le modèle relationnel ne s'excluent pas mutuellement. Les systèmes de sourcing d'événements incluent souvent les deux. La principale différence avec Event Sourcing est que le magasin d'entités n'est plus traité comme des données brutes. Il peut être remplacé ou reconstruit par un retraitement du journal des événements.
Dans les systèmes d'approvisionnement d'événements plus complexes, des magasins d'état dérivés doivent être présents pour des demandes de lecture efficaces, car la récupération de l'état actuel en traitant l'ensemble du journal des événements au fil du temps peut arrêter la mise à l'échelle. Les bases de données relationnelles et documentaires peuvent être utilisées à la fois comme journal des événements et comme référentiel pour les entités dérivées, grâce auxquelles vous pouvez obtenir rapidement l'état actuel. En fait, cette division des tâches est le CQRS (Command Query Responsibility Segregation, division des responsabilités en commandes et requêtes). Toutes les demandes sont acheminées vers le magasin dérivé afin qu'il puisse être optimisé indépendamment des opérations d'écriture.
Outre la partie technique, il y a d'autres points qui méritent d'être pris en compte.
Problèmes potentiels d'approvisionnement en événements
Malgré les avantages de Event Sourcing, il présente également des inconvénients.
Les plus grands défis résident généralement dans l'état d'esprit des développeurs. Les développeurs doivent aller au-delà des applications CRUD conventionnelles et des magasins d'entités. Les événements devraient maintenant devenir le concept principal.
Avec Event Sourcing, beaucoup d'efforts sont consacrés à la modélisation d'événements. Une fois que les événements sont écrits dans le journal, ils doivent être considérés comme inchangés, sinon, l'historique et l'état peuvent être corrompus ou corrompus. Le journal des événements est constitué des données brutes, ce qui signifie que vous devez être très prudent pour vous assurer qu'il contient toutes les informations nécessaires pour obtenir l'état complet du système à un moment donné. Il convient également de garder à l'esprit que les événements peuvent être réinterprétés à mesure que le système (et l'activité qu'il représente) évolue au fil du temps. Et n'oubliez pas les événements erronés et suspects avec un traitement correct de la validation des données.
Pour les modèles de domaine simples, ce changement de pensée peut être assez facile, mais pour les modèles de domaine plus complexes, cela peut être un problème (en particulier avec beaucoup de dépendances et de relations entre entités). Il peut être difficile de s'intégrer à des systèmes externes qui ne fournissent pas de données à un moment donné.
L'approvisionnement d'événements peut bien fonctionner sur de grands systèmes car le modèle de journal des événements évolue naturellement horizontalement. Par exemple, le journal des événements d'une entité ne doit pas nécessairement résider physiquement avec le journal des événements d'une autre entité. Cependant, cette facilité de mise à l'échelle entraîne des problèmes supplémentaires sous la forme d'un traitement asynchrone et éventuellement de données cohérentes. Les commandes pour modifier l'état peuvent arriver à n'importe quel nœud, après quoi le système doit déterminer quels nœuds sont responsables des entités correspondantes et envoyer la commande à ces nœuds, puis traiter la commande, puis répliquer les événements générés vers d'autres nœuds où les journaux d'événements sont stockés. Et seulement après l'achèvement de ce processus, le nouvel événement devient disponible dans le cadre de l'état du système.Ainsi, Event Sourcing nécessite en fait que le traitement des commandes soit séparé de la demande d'état, c'est-à-dire CQRS.
Par conséquent, les systèmes Event Sourcing doivent prendre en compte l'intervalle de temps entre l'émission d'une commande et la réception d'une notification concernant la réussite de la journalisation des événements. L'état du système que les utilisateurs voient à ce moment peut être «faux». Ou plutôt, un peu dépassé. Pour réduire l'influence de ce facteur, il est nécessaire de le prendre en compte lors de la conception de l'interface utilisateur et dans d'autres composants. Il est également nécessaire de gérer correctement les situations où une commande échoue, est annulée pendant l'exécution ou lorsqu'un événement est remplacé par un événement plus récent lorsque les données sont mises à jour.
Un autre problème se posera lorsque les événements s'accumulent au fil du temps et qu'il sera nécessaire de travailler avec eux. C'est une chose de simplement les écrire après le traitement, c'en est une autre de travailler avec toute l'histoire. Sans cette fonctionnalité, le journal des événements perd complètement sa valeur. Cela est particulièrement vrai pour la reprise après sinistre ou lors de la migration de magasins dérivés, lorsque tous les événements doivent être retraités pour mettre à jour les données. Pour les systèmes comportant un grand nombre d'événements, le retraitement de l'intégralité du journal peut dépasser le temps de récupération autorisé. Des instantanés périodiques du système peuvent vous aider ici afin que vous puissiez commencer à récupérer à partir d'un état sain ultérieur.
Il est également nécessaire de considérer la structure des événements. La structure des événements peut changer avec le temps. L'ensemble des champs peut changer. Il peut y avoir des situations où d'anciens événements doivent être traités par la logique métier actuelle. Et la présence d'un programme d'événements extensible aidera à l'avenir, si nécessaire, à distinguer les nouveaux événements des anciens. Des instantanés périodiques aident également à isoler les changements majeurs dans la structure des événements.
conclusions
Event Sourcing est une approche puissante avec des avantages. L'un d'eux est de faciliter l'extension du système à l'avenir. Étant donné que le journal des événements stocke tous les événements, ils peuvent être utilisés dans des systèmes externes. Il est assez facile à intégrer en ajoutant de nouveaux gestionnaires d'événements.
Cependant, comme pour toute décision architecturale majeure, vous devez faire attention à ce que cela fonctionne pour votre situation. Contraintes liées à la complexité du domaine, aux exigences de cohérence et de disponibilité des données, ainsi qu'à l'augmentation du volume de données stockées et à l'évolutivité sur le long terme, tout cela doit être pris en compte (et il ne s'agit en aucun cas d'une liste exhaustive). Il est également important de prêter attention aux développeurs qui développeront et maintiendront un tel système tout au long de son cycle de vie.
Et enfin, n'oubliez pas le principe le plus important de l'ingénierie logicielle - efforcez-vous de tout garder aussi simple que possible (le principe KISS).
