Υπάρχουν πράγματα στο software που φαίνονται τόσο απλά, ώστε συνήθως τα θεωρούμε δεδομένα. Μία ημερομηνία, για παράδειγμα. Τι μπορεί να είναι δύσκολο σε μία ημερομηνία;
Πολύ περισσότερα απ’ όσα φαίνονται! Σε ένα συνηθισμένο πληροφοριακό σύστημα, ίσως αρκεί να γνωρίζεις ότι σήμερα είναι Δευτέρα 20 Οκτωβρίου. Σε ένα σύστημα που υποστηρίζει χρηματοοικονομικές συναλλαγές, corporate actions ή διαδικασίες κεφαλαιαγοράς, αυτό δεν αρκεί. Η πραγματική ερώτηση είναι διαφορετική!
Είναι σήμερα εργάσιμη ημέρα; Και ακόμη κι αυτή η ερώτηση δεν έχει πάντοτε μία μοναδική απάντηση. Εργάσιμη για ποιον; Για την εταιρεία; Για το χρηματιστήριο; Για την τράπεζα πληρωμών; Για το κεντρικό αποθετήριο; Για μία αγορά στην Αθήνα, στο Λονδίνο ή στη Νέα Υόρκη; Κάπου εκεί καταλαβαίνεις ότι το ημερολόγιο παύει να είναι ένα απλό βοηθητικό table και γίνεται μέρος της επιχειρησιακής λογικής του συστήματος.
Ας πάρουμε ένα απλό παράδειγμα. Μία πληρωμή μερίσματος πρέπει να πραγματοποιηθεί δύο εργάσιμες ημέρες μετά από κάποιο συγκεκριμένο γεγονός. Ακούγεται εύκολο. Προσθέτεις δύο ημέρες. Μόνο που η πρώτη μπορεί να είναι Παρασκευή. Κια η Δευτέρα μπορεί να είναι τραπεζική αργία. Η Τρίτη μπορεί να είναι εργάσιμη στην Ελλάδα αλλά όχι στη χώρα στην οποία βρίσκεται ο paying agent. Και αν υπάρχουν διαφορετικές αγορές ή διαφορετικά νομίσματα, το πρόβλημα γίνεται ακόμη πιο ενδιαφέρον. Το «+2 ημέρες» δεν σημαίνει πλέον:
date.AddDays(2). Σημαίνει:
«Βρες τις δύο επόμενες ημέρες κατά τις οποίες όλοι οι απαραίτητοι συμμετέχοντες μπορούν πράγματι να εκτελέσουν τη συγκεκριμένη διαδικασία». Και αυτό είναι business logic. Και γι’ αυτό τα Business Calendars πρέπει να αντιμετωπίζονται ως πραγματικά domain objects. Πρέπει να γνωρίζουν αργίες, weekends, special closing days, μεταφερόμενες αργίες και ενδεχομένως διαφορετικά calendars ανά αγορά, χώρα ή διαδικασία. Και ύστερα έρχονται τα time zones. Ένα γεγονός που συμβαίνει στις 23:30 στη Νέα Υόρκη μπορεί ήδη να ανήκει στην επόμενη ημερολογιακή ημέρα στην Αθήνα. Ακόμη χειρότερα, υπάρχουν περίοδοι μέσα στο έτος όπου η διαφορά ώρας μεταξύ δύο χωρών αλλάζει προσωρινά, επειδή η αλλαγή σε θερινή ώρα δεν γίνεται την ίδια ημερομηνία παντού. Αν το σύστημα βασίζεται σε υποθέσεις όπως «Αθήνα και Νέα Υόρκη έχουν πάντα επτά ώρες διαφορά», κάποια στιγμή θα αποτύχει. Και πιθανότατα θα αποτύχει την ημέρα που δεν πρέπει! Αυτό είναι ένα από τα χαρακτηριστικά των mission-critical συστημάτων που προσωπικά θεωρώ ιδιαίτερα ενδιαφέρον. Οι δυσκολότεροι κανόνες πολλές φορές δεν βρίσκονται στις μεγάλες, εντυπωσιακές λειτουργίες. Κρύβονται στις λεπτομέρειες. Σε μία αργία. Σε μία ώρα. Σε ένα cut-off. Σε μία ημερομηνία που μετακινείται επειδή πέφτει Κυριακή. Και αυτές ακριβώς οι λεπτομέρειες είναι που ξεχωρίζουν ένα σύστημα που απλώς «δουλεύει» από ένα σύστημα στο οποίο μπορείς πραγματικά να βασιστείς.
Υπάρχει και κάτι ακόμη. Τα ημερολόγια δεν πρέπει να είναι hard-coded. Οι αγορές αλλάζουν. Οι αργίες αλλάζουν. Μπορεί να υπάρξουν έκτακτες ημέρες κατά τις οποίες μία αγορά παραμένει κλειστή. Άρα το calendar model πρέπει να είναι παραμετρικό, versioned και —σε σοβαρά χρηματοοικονομικά συστήματα— να επιτρέπει να γνωρίζουμε όχι μόνο ποιο ημερολόγιο ισχύει σήμερα, αλλά και ποιο ημερολόγιο ίσχυε όταν εκτελέστηκε μία συναλλαγή στο παρελθόν. Γιατί αν ξανατρέξεις μία παλιά διαδικασία, πρέπει να πάρεις το ίδιο αποτέλεσμα. Αυτό είναι determinism. Και τότε συνειδητοποιείς ότι ένα Business Calendar δεν είναι απλώς μία λίστα από ημερομηνίες. Είναι μέρος της αρχιτεκτονικής. Μέρος του auditability. Μέρος του risk management. Και τελικά μέρος της αξιοπιστίας του ίδιου του συστήματος. Στο enterprise software έχω μάθει να είμαι ιδιαίτερα καχύποπτος απέναντι σε requirements που ξεκινούν με τη φράση:
«Είναι απλό. Απλώς…» Πολύ συχνά, ακριβώς μετά από αυτό το «απλώς» κρύβεται ο πραγματικός επιχειρησιακός κανόνας.
Δεν υπάρχουν σχόλια:
Δημοσίευση σχολίου