"Event Sourcing + DCB" et le règne de la pensée magique

Mon post précédent invitait à modéliser/concevoir une solution pour un cas concret d'invariant systémique :

La home page d'un utilisateur de Klaro Cards doit être un board auquel il a accès

J'ai reçu plusieurs fois la réponse :

Simple : ES + DCB 🥳

(En clair dans le texte : Event Sourcing + Dynamic Consistent Boundaries)

Pour les non initiés, ES DCB c'est une méthode de gestion de l'état d'un système qui consiste à:

1️⃣ conserver l'ensemble des événements observés du système (ES)

2️⃣ vérifier l'invariant dynamiquement en fonction d'une définition de ce dernier sur base des événements (DCS).

La technique est une bonne candidate pour l'exercice proposé : événements et invariants offrent certainement une bonne base de réflexion.

Il faudrait éviter par contre de confondre "base de réflexion" et "réflexion".

En d'autres termes, je m'intéresse moins aux claims "magique magique, avec ma super techno générique je peux calculer ce que je veux" qu'à la "formule exacte à utiliser" 😉

Créer du logiciel tient bien plus du réel du second que de la magie du premier : c'est à la phase d'analyse qu'on se trompe le plus souvent.

D'où la question initiale.

#SoftwareEngineering #Architecture

Go back