Εφαρμογή Καθαρής Αρχιτεκτονικής με το Nest.JS

Αυτό το άρθρο απευθύνεται σε λάτρεις που προσπαθούν να γράψουν καθαρό, επεκτάσιμο και, το πιο σημαντικό, ανανεώσιμο κώδικα. Θα δώσει μια ιδέα για το πώς το Nest.JS μπορεί να μας βοηθήσει να γράψουμε καθαρό κώδικα και ποια υποκείμενη αρχιτεκτονική χρησιμοποιεί.

Η εφαρμογή μιας καθαρής αρχιτεκτονικής με το Nest.JS θα απαιτήσει πρώτα να κατανοήσουμε τι είναι αυτό το πλαίσιο και πώς λειτουργεί.

Το Nest ή το Nest.JS είναι ένα πλαίσιο για τη δημιουργία αποτελεσματικών, επεκτάσιμων εφαρμογών Node.js (από την πλευρά του διακομιστή) που έχουν κατασκευαστεί με TypeScript. Χρησιμοποιεί Express ή Fastify και επιτρέπει ένα επίπεδο αφαίρεσης για να επιτρέψει στους προγραμματιστές να χρησιμοποιούν άφθονη ποσότητα λειτουργικών μονάδων (τρίτου κατασκευαστή) στον κώδικά τους.

Ας σκάψουμε βαθύτερα σε τι είναι αυτή η καθαρή αρχιτεκτονική. 

Λοιπόν, όλοι ίσως έχετε χρησιμοποιήσει ή τουλάχιστον έχετε ακούσει για την αρχιτεκτονική MVC. Το MVC σημαίνει Model, View, Controller. Η ιδέα πίσω από αυτό είναι να χωρίσουμε τη δομή του έργου μας σε 3 διαφορετικές ενότητες.

1. Μοντέλο: Θα περιέχει το αρχείο Αντικειμένου που αντιστοιχίζεται με Σχέση/Έγγραφα στο ΒΔ.

2. Ελεγκτής: Είναι ο χειριστής αιτημάτων και είναι υπεύθυνος για την υλοποίηση της επιχειρηματικής λογικής και όλων των χειρισμών των δεδομένων.

3. Προβολή: Αυτό το μέρος θα περιέχει αρχεία που αφορούν την εμφάνιση των δεδομένων, είτε αρχεία HTML είτε ορισμένα αρχεία μηχανών προτύπων.

Για να δημιουργήσουμε ένα μοντέλο, χρειαζόμαστε κάποιο είδος εργαλείου/μονάδας/βιβλιοθήκης ORM/ODM για να το δημιουργήσουμε. Για παράδειγμα, εάν χρησιμοποιείτε απευθείας τη λειτουργική μονάδα, ας πούμε "sequelize" και, στη συνέχεια, χρησιμοποιήστε το ίδιο για να εφαρμόσετε τη σύνδεση στον ελεγκτή σας και να εξαρτήσετε τη βασική επιχειρηματική σας λογική από τη "sequelize". Τώρα, στη συνέχεια, ας πούμε μετά από 10 χρόνια, υπάρχει ένα καλύτερο εργαλείο στην αγορά που θέλετε να χρησιμοποιήσετε, αλλά μόλις αντικαταστήσετε το sequelise με αυτό, θα πρέπει να αλλάξετε πολλές γραμμές κώδικα για να το αποτρέψετε σπάσιμο. Επίσης, θα πρέπει να δοκιμάσετε ξανά όλες τις δυνατότητες για να ελέγξετε αν έχει αναπτυχθεί με επιτυχία ή όχι, κάτι που μπορεί επίσης να σπαταλήσει πολύτιμο χρόνο και πόρους. Για να ξεπεράσουμε αυτήν την πρόκληση, μπορούμε να χρησιμοποιήσουμε την τελευταία αρχή του SOLID που είναι η Αρχή της Αντιστροφής Εξάρτησης, και μια τεχνική που ονομάζεται έγχυση εξάρτησης για να αποφύγουμε ένα τέτοιο χάος.

Ακόμα μπερδεμένος? Επιτρέψτε μου να σας εξηγήσω αναλυτικά.

Έτσι, αυτό που λέει με απλά λόγια η Αρχή Αντιστροφής Εξάρτησης είναι ότι δημιουργείτε τη βασική επιχειρηματική σας λογική και στη συνέχεια χτίζετε την εξάρτηση γύρω από αυτήν. Με άλλα λόγια, απελευθερώστε τη βασική λογική και τους επιχειρηματικούς κανόνες σας από κάθε είδους εξάρτηση και τροποποιήστε τα εξωτερικά στρώματα με τέτοιο τρόπο ώστε να εξαρτώνται από τη βασική σας λογική αντί να εξαρτώνται από αυτήν. Αυτό είναι η καθαρή αρχιτεκτονική. Αφαιρεί την εξάρτηση από τη βασική επιχειρηματική σας λογική και χτίζει το σύστημα γύρω από αυτό με τέτοιο τρόπο που φαίνεται να εξαρτώνται από αυτήν και όχι να εξαρτώνται από αυτούς.

Ας προσπαθήσουμε να το καταλάβουμε αυτό με το παρακάτω διάγραμμα.

πηγή: Clean Architecture Cone 

Μπορείτε να δείτε ότι έχουμε χωρίσει την αρχιτεκτονική μας σε 4 επίπεδα:

1. Οντότητες: Στον πυρήνα της, οι οντότητες είναι τα μοντέλα (Εταιρικοί κανόνες) που καθορίζουν τους κανόνες της επιχείρησής σας και λένε τι αφορά η εφαρμογή. Αυτό το επίπεδο δύσκολα θα αλλάξει με την πάροδο του χρόνου και είναι συνήθως αφηρημένο και δεν είναι άμεσα προσβάσιμο. Για παράδειγμα, κάθε εφαρμογή έχει έναν «χρήστη». Τα πεδία που πρέπει να αποθηκεύσει ο χρήστης, οι τύποι τους και οι σχέσεις τους με άλλες οντότητες θα αποτελούν μια οντότητα.

2. Περιπτώσεις χρήσης: Μας λέει πώς μπορούμε να εφαρμόσουμε τους εταιρικούς κανόνες. Ας πάρουμε ξανά το παράδειγμα του χρήστη. Τώρα ξέρουμε ποια δεδομένα πρέπει να λειτουργήσουμε, η περίπτωση χρήσης μας λέει πώς να λειτουργήσουμε με αυτά τα δεδομένα, όπως ο χρήστης θα έχει έναν κωδικό πρόσβασης που πρέπει να κρυπτογραφηθεί, ο χρήστης πρέπει να δημιουργηθεί και ο κωδικός πρόσβασης μπορεί να αλλάξει οποιαδήποτε στιγμή δεδομένη χρονική στιγμή κ.λπ.

3. Ελεγκτές/Πύλες: Αυτά είναι κανάλια που μας βοηθούν να υλοποιήσουμε τις περιπτώσεις χρήσης χρησιμοποιώντας εξωτερικά εργαλεία και βιβλιοθήκες χρησιμοποιώντας ένεση εξάρτησης.

4. Εξωτερικά εργαλεία: Όλα τα εργαλεία και οι βιβλιοθήκες που χρησιμοποιούμε για να δημιουργήσουμε τη λογική μας θα υπάγονται σε αυτό το επίπεδο π.χ. ORM, Emailer, Κρυπτογράφηση κ.λπ.

Τα εργαλεία που χρησιμοποιούμε θα εξαρτώνται από τον τρόπο με τον οποίο τα διοχετεύουμε σε περιπτώσεις χρήσης και με τη σειρά τους, οι περιπτώσεις χρήσης θα εξαρτηθούν από τις οντότητες που αποτελούν τον πυρήνα της επιχείρησής μας. Με αυτόν τον τρόπο έχουμε αντιστρέψει την εξάρτηση από προς τα έξω προς τα μέσα. Αυτό υπονοεί το Dependency Inversion Principal του SOLID.

Εντάξει, μέχρι τώρα, έχετε καταλάβει την ουσία του Nest.JS και καταλάβατε πώς λειτουργεί η καθαρή αρχιτεκτονική. Τώρα τίθεται το ερώτημα, πώς συνδέονται αυτά τα δύο;  

Ας προσπαθήσουμε να καταλάβουμε ποια είναι τα 3 δομικά στοιχεία του Nest.JS και τι κάνει το καθένα από αυτά.

1. Ενότητες: Το Nest.JS είναι δομημένο με τέτοιο τρόπο ώστε να μπορούμε να αντιμετωπίζουμε κάθε χαρακτηριστικό ως μια λειτουργική μονάδα. Για παράδειγμα, οτιδήποτε συνδέεται με τον Χρήστη, όπως μοντέλα, ελεγκτές, DTO, διεπαφές κ.λπ., μπορεί να διαχωριστεί ως λειτουργική μονάδα. Μια μονάδα έχει έναν ελεγκτή και μια δέσμη παρόχων που είναι ενέσιμες λειτουργίες όπως υπηρεσίες, orm, emailer κ.λπ.

2. Ελεγκτές: Οι ελεγκτές στο Nest.JS είναι διεπαφές μεταξύ του δικτύου και της λογικής σας. Χρησιμοποιούνται για το χειρισμό αιτημάτων και την επιστροφή απαντήσεων στην πλευρά του πελάτη της εφαρμογής (για παράδειγμα, κλήση στο API).

3. Πάροχοι (Υπηρεσίες): Οι πάροχοι είναι ενέσιμες υπηρεσίες/λειτουργίες τις οποίες μπορούμε να εισάγουμε στους ελεγκτές και σε άλλους παρόχους για να παρέχουμε ευελιξία και επιπλέον λειτουργικότητα. Αφαιρούν κάθε μορφή πολυπλοκότητας και λογικής.

Να συνοψίσουμε,

• Έχουμε ελεγκτές που λειτουργούν ως διεπαφές (3ο επίπεδο καθαρής αρχιτεκτονικής)
• Έχουμε παρόχους που μπορούν να εγχυθούν για να παρέχουν λειτουργικότητα (4ο επίπεδο καθαρής αρχιτεκτονικής: DB, Συσκευές κ.λπ.)
• Μπορούμε επίσης να δημιουργήσουμε υπηρεσίες και αποθετήρια για να ορίσουμε την περίπτωση χρήσης μας (2ο Επίπεδο)
• Μπορούμε να ορίσουμε τις οντότητες μας χρησιμοποιώντας παρόχους DB (1st Layer)

Συμπέρασμα:

Το Nest.JS είναι ένα ισχυρό πλαίσιο Node.JS και το πιο γνωστό πληκτρολόγιο που είναι διαθέσιμο σήμερα. Τώρα που έχετε το χαμηλό σε αυτό το πλαίσιο, πρέπει να αναρωτιέστε αν μπορούμε να το χρησιμοποιήσουμε για να δημιουργήσουμε μια δομή έργου με καθαρή αρχιτεκτονική. Λοιπόν, η απάντηση είναι -Ναι! Απολύτως. Πως? Θα εξηγήσω στην επόμενη σειρά αυτού του άρθρου. 

Μέχρι τότε, μείνετε συντονισμένοι!

Σχετικά με το Συντάκτης:

Ο Junaid Bhat αυτή τη στιγμή εργάζεται ως επικεφαλής τεχνολογίας στα Mantra Labs. Είναι ένας λάτρης της τεχνολογίας που προσπαθεί να γίνει καλύτερος μηχανικός καθημερινά ακολουθώντας τα πρότυπα της βιομηχανίας και ευθυγραμμισμένος προς μια πιο δομημένη προσέγγιση για την επίλυση προβλημάτων. 

Διαβάστε το τελευταίο μας blog: Το πλαίσιο Golang-Beego και οι εφαρμογές του

Οι γνώσεις που αξίζει να παραδοθούν στα εισερχόμενά σας