(En construction, je teste avec bolt.new) Une fois le modèle prêt:
Donner à l'IA (lovable, bolt.new) le contexte d'architecture :
COnstruire une application, sur une page, front end UI et back end, je veux utiliser :
1. Event Sourcing & CQRS : chaque changement d'état est un évènement immuable, stocké dans Event Store DB pour garantir l'auditabilité, la traçabilité et la reconstruction complète de l'état.
2. Slice architecture : chaque slice du modèle correspond à un répertoire dédié dans le code, encapsulant ses commandes, évènements, projections et handlers.
3. Slice de changement d'état (automation) : elle se fera avec une Command et un Command Handler pour appliquer les règles métier et générer les évènements associés.
4. Slice de vue d'état : elle se fera avec une Query et un Query Handler, via un mécanisme publish & subscribe, afin de fournir des vues réactives de l'état.
5. Projection : chaque slice de vue d'état doit posséder deux icônes de contrôle — "Empty Projection" pour supprimer la projection actuelle et "Rebuild Projection" pour reconstruire la projection à partir de l'historique des évènements.
6. Automate (automation) : il applique le principe du Todo Pattern List ; il se déclenche via une subscription aux évènements et un scheduler qui exécute un cycle toutes les 2 secondes.
7. Logique du Todo Pattern : l'automate lit les évènements souscrits ainsi que les évènements publiés. Si un évènement souscrit existe sans évènement publié correspondant pour un même aggregateId, alors l'automate traite cet évènement.
8. Translation (adapter pattern) : la traduction se fera par un copier/coller des données pertinentes avec un nouvel aggregateId pour créer un nouvel agrégat et l’évènement correspondant.
9. Event Store DB : tous les évènements sont stockés dans Event Store DB pour garantir immutabilité et reconstruction complète.
10. Organisation : les évènements sont centralisés dans un répertoire commun nommé "Events" afin d’assurer cohérence et réutilisation.
11. Les évènements seront affichés en bas de la page, chronoligiquement du plus récent au plus ancien.
Changement d’état
Correspond aux commandes et à leurs gestionnaires (command / commandHandler).Une action de l’utilisateur ou du système modifie l’état, et génère des événements stockés dans Event Store DB.
Vue de l’état
Correspond aux projections et aux queries.Elles peuvent être vidées et reconstruites à partir de l’historique des événements.
On peut utilisant un mécanisme publish/subscribe pour fournir ces projections: eventHandler (pub/sub).
Chaque projection a deux contrôles : « Empty Projection » et « Rebuild Projection » qui rejouent les évènements auquel la projection a souscrit.
Automatisation
Correspond aux mécanismes pub/sub et au Todo Pattern List.Un automate lit les événements souscrits et déclenche des actions via un scheduler (toutes les 2 secondes).
Si un évènement attendu n’a pas encore produit de sortie correspondante (même aggregateId), l’automate le traite.
Traduction
Quand un événement externe est traduit en événement interne via un adapter pattern.Cela consiste à copier/coller les données pertinentes, créer un nouvel aggregateId, puis publier le nouvel évènement.
Explication du modèle JSON :
Ce JSON représente la structure de données utilisée pour décrire l’architecture et les éléments clés de l’application.
Il sert de base à l’IA pour comprendre la configuration, les relations et les processus.
1. `slices` : liste des différentes slices du modèle, chacune correspondant à une partie fonctionnelle de l’application.
2. `commands` : liste des commandes associées à chaque slice pour déclencher des changements d’état.
3. `events` : définition des évènements immuables générés par les commandes et stockés dans Event Store DB.
4. `queries` : liste des requêtes permettant de consulter l’état via les projections.
5. `projections` : vues construites à partir des évènements, représentant l’état actuel d’une slice.
6. `automations` : logique métier déclenchée par des évènements, définie dans les slices de changement d’état.
7. `settings` : configuration générale incluant scheduler, fréquence d’exécution et règles spécifiques.
8. `metadata` : informations supplémentaires pour contextualiser les données (version, date, auteur, etc.).