Business logic validation σε e-shop και booking εφαρμογές: όταν τα σωστά πεδία δίνουν λάθος αποτέλεσμα

Σε μια custom εφαρμογή, ένα πεδίο μπορεί να έχει σωστό format και παρόλα αυτά να δημιουργεί λάθος αποτέλεσμα. Η ποσότητα μπορεί να είναι αριθμός, αλλά να ξεπερνά το stock. Η ημερομηνία μπορεί να είναι valid, αλλά να είναι σε κλειστή ημέρα. Η έκπτωση μπορεί να είναι σωστό ποσοστό, αλλά να μην επιτρέπεται για το συγκεκριμένο προϊόν.

Αυτό είναι business logic validation. Δεν ελέγχει μόνο αν τα δεδομένα είναι καλοσχηματισμένα. Ελέγχει αν βγάζουν νόημα για τη συγκεκριμένη επιχειρησιακή διαδικασία.

Input validation και business validation

Το OWASP διαχωρίζει τη συντακτική και τη σημασιολογική εγκυρότητα. Συντακτικά, ένα email πρέπει να μοιάζει με email και μια τιμή με αριθμό. Σημασιολογικά, η τιμή πρέπει να είναι επιτρεπτή για το προϊόν, τον πελάτη και τη στιγμή της αγοράς.

Παράδειγμα e-shop:

• quantity: 3 είναι τεχνικά σωστό
• αν υπάρχουν μόνο 2 τεμάχια, είναι επιχειρησιακά λάθος

Παράδειγμα booking:

• 2026-09-15 είναι έγκυρη ημερομηνία
• αν το κατάστημα είναι κλειστό εκείνη την ημέρα, η κράτηση πρέπει να απορριφθεί

Μην εμπιστεύεστε client-side τιμές

Ένα συνηθισμένο λάθος είναι να στέλνει το frontend τιμή, έκπτωση ή τελικό ποσό και ο server να το δέχεται. Ο χρήστης μπορεί να αλλάξει request payload, hidden fields ή JavaScript state.

Ο server πρέπει να υπολογίζει ξανά:

• τιμή προϊόντος
• διαθέσιμο stock
• φόρους
• μεταφορικά
• εκπτωτικά κουπόνια
• δικαιώματα χρήστη
• κατάσταση παραγγελίας ή κράτησης

Το frontend βοηθά την εμπειρία. Δεν είναι πηγή αλήθειας.

Workflows ως state machines

Σε multi-step διαδικασίες, όπως checkout, booking, αίτηση πελάτη ή approval, η σειρά βημάτων πρέπει να ελέγχεται server-side.

Παράδειγμα booking:

• draft
• selected slot
• customer details
• payment pending
• confirmed
• cancelled

Δεν πρέπει ο χρήστης να μπορεί να πηδήξει απευθείας στο confirmed state επειδή κάλεσε ένα endpoint. Κάθε μετάβαση πρέπει να είναι επιτρεπτή από την τρέχουσα κατάσταση.

Race conditions

Αν δύο χρήστες προσπαθούν να κλείσουν το ίδιο slot ή να αγοράσουν το τελευταίο προϊόν, χρειάζεται atomic έλεγχος. Δεν αρκεί να ελέγξετε διαθεσιμότητα και μετά να γράψετε την κράτηση χωρίς lock ή transaction.

Πρακτικά:

• database transactions
• unique constraints όπου γίνεται
• idempotency keys για πληρωμές και external actions
• επανέλεγχος stock πριν την επιβεβαίωση
• καθαρά errors όταν η θέση ή το προϊόν δεν είναι πλέον διαθέσιμο

Κουπόνια και εκπτώσεις

Τα κουπόνια είναι κλασικό σημείο business logic bugs.

Πρέπει να ελέγχονται:

• ημερομηνία ισχύος
• προϊόντα ή κατηγορίες όπου εφαρμόζεται
• ελάχιστη αξία καλαθιού
• μέγιστη χρήση ανά πελάτη
• αν συνδυάζεται με άλλες εκπτώσεις
• αν ισχύει για συγκεκριμένο customer segment

Αν αυτά δεν ελέγχονται server-side, το σύστημα μπορεί να κάνει νόμιμη τεχνικά αλλά λάθος εμπορικά έκπτωση.

Πώς το κάνει η Ai Foundry

Στην Ai Foundry σχεδιάζουμε e-shop, booking systems, CRM και portals με business rules πριν την υλοποίηση endpoints. Καταγράφουμε ποια δεδομένα είναι πηγή αλήθειας, ποιες καταστάσεις επιτρέπονται, ποιες ενέργειες χρειάζονται transaction και ποια errors πρέπει να βλέπει ο χρήστης.

Αυτό είναι κρίσιμο σε custom εφαρμογές όπου η αξία δεν είναι απλώς το UI, αλλά η σωστή εκτέλεση της διαδικασίας. Η Ai Foundry μπορεί να ενώσει UX, backend validation, payments, stock, approvals και audit logs σε μια εφαρμογή που λειτουργεί με πραγματικούς επιχειρησιακούς κανόνες.

Checklist

Ελέγξτε:

• αν ο server υπολογίζει τιμές και εκπτώσεις
• αν το stock ελέγχεται πριν την επιβεβαίωση
• αν τα workflows έχουν server-side states
• αν υπάρχουν transactions για κρίσιμες ενέργειες
• αν τα κουπόνια έχουν σαφείς κανόνες
• αν permissions και ownership ελέγχονται ανά αντικείμενο
• αν υπάρχουν tests για λάθος σειρά βημάτων
• αν υπάρχει logging για ύποπτα business rule failures

Το business logic validation είναι η διαφορά ανάμεσα σε εφαρμογή που φαίνεται σωστή και εφαρμογή που αντέχει πραγματική χρήση.