Event sourcing pattern : Χρησιμότητα και βήμα βήμα επεξήγηση!
Για να αυξήσουμε την αξιοπιστία ενός συστήματος, χρειάζεται να καταγράφουμε την κάθε ενέργεια, ιδιαίτερα σε κρίσιμες οντότητες. Το event sourcing είναι ένα design pattern, ανεξάρτητο από γλώσσες προγραμματισμού, το οποίο αποτελεί οδηγό στο πώς να επιτύχουμε σωστά τα παραπάνω.
Πολλές φορές σε συστήματα όταν δημιουργηθεί ένα σοβαρό ζήτημα, όλοι αναρωτιούνται πότε συνέβη και ποιός χρήστης έκανε αυτήν την ενέργεια.
Καταγράφοντας λοιπόν την κάθε ενέργεια σε ένα entity - οντότητα με έναν απλό και έξυπνο τρόπο, επιτυγχάνουμε, εκτός από το πλήρες ιστορικό ενεργειών και την χρήσιμη δυνατότητα να κάνουμε undo/redo αλλάζοντας δηλαδή εύκολα το state ενός αντικειμένου σε παρελθοντικό ή μελλοντικό (αν υπάρχει) αντίστοιχα χρόνο.
Για λόγους απλότητας της επεξήγησης το οποίο θα βοηθήσει στην εύκολη κατανόηση, θα υποθέσουμε Α: πώς η εφαρμογή μας είναι μονολιθική, φυσικά τα events αυτά μπορούν εύκολα να στέλνονται και σε εξωτερικό microservice και Β : Το παράδειγμα θα αφορά ένα απλό entity.
Σχεδιάζουμε λοιπόν υποθετικά, μια εφαρμογή όπου θέλουμε να γνωρίζουμε τα πάντα για ένα προϊόν. Το model μας λοιπόν θα περιέχει τα εξής :
[products]
product_id : To ID του προϊόντος
entity_event_id : Οι εγγραφές των events που δείχνουν στην κεφαλή του entity που καταγράφουμε τις ενέργειες του. Όταν είναι null σημαίνει πώς ειναι η κεφαλή.
name : Το όνομα του προιοντος
price : Η αξία του προϊόντος
action_user_id : Το ID του χρήστη που πραγματοποίησε μια οποιαδήποτε ενέργεια πάνω στο αντικείμενο. Για παράδειγμα δημιουργία, επεξεργασία, διαγραφή.
entity_status_id : Θα έχει πολλές καταστάσεις π.χ ενεργό, απενεργοποιημένο, διαγραμμένο
created_at : Ημερομηνία και ώρα που πραγματοποιήθηκε το συμβάν.
Τι επιτυγχανουμε με τον παραπάνω εξαιρετικά εύκολο σχεδιασμό :
- Γνωρίζουμε ποιός χρήστης, πότε και με ποιές τιμές άλλαξε ένα αντικείμενο. Πότε το δημιούργησε και με ποιες αρχικές τιμές, πότε έκανε επεξεργασία και με ποιές τιμές, πότε το διέγραψε ή άλλαξε την κατάσταση του κ.α.
- Μπορούμε εύκολα και χωρίς να γράψουμε νέα methods ή να σχεδιάσουμε νέα models, να προβάλουμε κατά το δοκούν, είτε την κεφαλή είτε τα events της κεφαλής. Σκεφτείτε ενα κακο design όπου για κάθε model χρειαζόμαστε και ένα ακόμα model για το log του! Περιττές γραμμές κώδικα, περιττά models, ανούσια μεγέθυνση του project.
- Να έχουμε πλήρες reporting αυξάνοντας κατακόρυφα την αξιοπιστία του συστήματος μας.
- Να μπορούμε εύκολα να εισάγουμε μηχανισμούς undo/redo αλλά και να “ταξιδέψουμε” χρονικά στο αντικείμενο αυτό.
- Να μπορούμε να προβάλουμε συνάρτηση του χρόνου π.χ την εξέλιξη της τιμής ή ανάλογα ότι άλλο μπορεί να μας ζητηθεί.
Αυτά τα λίγα αλλά χρήσιμα και όμορφα πραγματάκια.
Ελπίζω το άρθρο μου να σας φάνηκε χρήσιμο.
Προσίλης Αργύρης
Software engineer
PHP/Laravel, Golang, ReactJS
