Πώς να μάθετε το σχεδιασμό και την αρχιτεκτονική λογισμικού - έναν χάρτη πορείας

Αυτό το άρθρο είναι μια περίληψη αυτού που γράφω στο πιο πρόσφατο έργο μου, solidbook.io - The Handbook to Software Design and Architecture with TypeScript. Ρίξτε μια ματιά ότι σας αρέσει αυτή η ανάρτηση.

Είναι τρελό για μένα να σκεφτώ το γεγονός ότι το Facebook ήταν κάποτε ένα κενό αρχείο κειμένου στον υπολογιστή κάποιου.

Χαχαχα.

Τον περασμένο χρόνο, έχω πάει σκληρά στον σχεδιασμό και την αρχιτεκτονική λογισμικού, το Domain-Driven Design και γράφω ένα βιβλίο σε αυτό και ήθελα να αφιερώσω λίγο χρόνο για να το συνδυάσω σε κάτι χρήσιμο που θα μπορούσα να μοιραστώ με την κοινότητα .

Αυτός είναι ο χάρτης πορείας μου για τον τρόπο εκμάθησης του σχεδιασμού και της αρχιτεκτονικής του λογισμικού.

Το έχω χωρίσει σε δύο αντικείμενα: τη στοίβα και τον χάρτη .

Η στοίβα

Παρόμοιο με το μοντέλο OSI στη δικτύωση, κάθε επίπεδο δημιουργείται πάνω από το θεμέλιο του προηγούμενου.

Η στοίβα

Ο χάρτης

Ενώ πιστεύω ότι η στοίβα είναι καλή για να δούμε τη μεγαλύτερη εικόνα του πώς λειτουργούν όλα μαζί, ο χάρτης είναι λίγο πιο λεπτομερής (και εμπνέεται από τον χάρτη πορείας για προγραμματιστές ιστού) και ως αποτέλεσμα, νομίζω ότι είναι πιο χρήσιμο.

Εδώ είναι παρακάτω! Για να πιέσετε το ρεπό, διαβάστε τη λεπτομερή εγγραφή μου και κατεβάστε το σε υψηλή ανάλυση, κάντε κλικ εδώ.

Χάρτης πορείας σχεδιασμού και αρχιτεκτονικής λογισμικού

Στάδιο 1: Καθαρός κώδικας

Το πρώτο βήμα για τη δημιουργία λογισμικού μεγάλης διάρκειας είναι να βρούμε πώς να γράφεις καθαρό κώδικα .

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

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

Η σύνταξη καθαρού κώδικα είναι εξαιρετικά σημαντική.

Σκεφτείτε το σαν ένα παιχνίδι της jenga.

Προκειμένου να διατηρηθεί η δομή του έργου μας σταθερή με την πάροδο του χρόνου, πράγματα όπως εσοχή, μικρές τάξεις και μέθοδοι και σημαντικά ονόματα, αποδίδουν πολλά μακροπρόθεσμα.

Ο καλύτερος πόρος για να μάθετε πώς να γράφετε καθαρό κώδικα είναι το βιβλίο του θείου Bob, "Clean Code".

Στάδιο 2: Παραδείγματα προγραμματισμού

Τώρα που γράφουμε αναγνώσιμο κώδικα που είναι εύκολο να διατηρηθεί, θα ήταν καλή ιδέα να κατανοήσουμε πραγματικά τα 3 μεγάλα παραδείγματα προγραμματισμού και τον τρόπο που επηρεάζουν τον τρόπο σύνταξης κώδικα.

Στο βιβλίο του θείου Μπομπ, "Clean Architecture", εφιστά την προσοχή στο γεγονός ότι:

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

Αυτό συνεπάγεται ότι το αποτελεσματικό λογισμικό χρησιμοποιεί υβριδικά και τα 3 στυλ παραδειγμάτων προγραμματισμού σε διαφορετικούς χρόνους.

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

Αν το μόνο που έχετε είναι σφυρί, όλα μοιάζουν με καρφί.

Πόροι

Για λειτουργικό προγραμματισμό , δείτε:

  • Ο επαρκής οδηγός του καθηγητή Frisby για λειτουργικό προγραμματισμό
  • Το μοντέλο μοντελοποίησης έγινε λειτουργικό

Στάδιο 3: Αντικειμενοστρεφής προγραμματισμός

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

Όχι μόνο ο αντικειμενοστρεφής προγραμματισμός μάς επιτρέπει να δημιουργήσουμε μια αρχιτεκτονική προσθηκών και να ενσωματώσουμε την ευελιξία στα έργα μας. Το OOP συνοδεύεται από τις 4 αρχές του OOP (ενθυλάκωση, κληρονομικότητα, πολυμορφισμός και αφαίρεση) που μας βοηθούν να δημιουργήσουμε μοντέλα πλούσιου τομέα .

Οι περισσότεροι προγραμματιστές που μαθαίνουν αντικειμενοστρεφή προγραμματισμό δεν φτάνουν ποτέ σε αυτό το μέρος: να μάθουν πώς να δημιουργούν μια εφαρμογή λογισμικού του προβληματικού τομέα και να τον εντοπίζουν στο κέντρο μιας πολυεπίπεδης εφαρμογής ιστού.

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

Γιατί είναι μια τεράστια συμφωνία;

Είναι τεράστιο γιατί αν μπορείτε να δημιουργήσετε ένα διανοητικό μοντέλο μιας επιχείρησης, μπορείτε να δημιουργήσετε μια εφαρμογή λογισμικού αυτής της επιχείρησης.

Στάδιο 4: Αρχές σχεδιασμού

Σε αυτό το σημείο, καταλαβαίνετε ότι ο Αντικειμενοστρεφής Προγραμματισμός είναι πολύ χρήσιμος για την ενσωμάτωση μοντέλων εμπλουτισμένων τομέων και την επίλυση του 3ου τύπου "Προβλήματα σκληρού λογισμικού" - Σύνθετοι τομείς.

Αλλά το OOP μπορεί να παρουσιάσει ορισμένες προκλήσεις στο σχεδιασμό.

Πότε πρέπει να χρησιμοποιώ σύνθεση;

Πότε πρέπει να χρησιμοποιώ κληρονομιά;

Πότε πρέπει να χρησιμοποιήσω μια αφηρημένη τάξη;

Οι αρχές σχεδίασης είναι πραγματικά καθιερωμένες και δοκιμασμένες στη μάχη βέλτιστες πρακτικές που προσανατολίζονται σε αντικείμενα που χρησιμοποιείτε ως προφυλακτήρες.

Μερικά παραδείγματα κοινών αρχών σχεδιασμού με τα οποία πρέπει να εξοικειωθείτε είναι:

  • Σύνθεση έναντι κληρονομιάς
  • Ενσωματώνει τι ποικίλλει
  • Πρόγραμμα κατά των αφαιρέσεων, όχι των σκυροδέματος
  • Η αρχή του Χόλιγουντ: "Μην μας καλέσετε, θα σας καλέσουμε"
  • Οι αρχές SOLID, ειδικά η αρχή της ενιαίας ευθύνης
  • ΣΤΕΓΝΟ (Μην επαναλάβετε τον εαυτό σας)
  • YAGNI (δεν θα το χρειαστείτε)

Φροντίστε όμως να καταλήξετε στα δικά σας συμπεράσματα. Μην ακολουθείτε απλώς αυτό που λέει κάποιος άλλος ότι πρέπει να κάνετε. Βεβαιωθείτε ότι έχει νόημα για εσάς.

Στάδιο 5: Σχέδια σχεδιασμού

Σχεδόν κάθε πρόβλημα στο λογισμικό έχει ήδη κατηγοριοποιηθεί και έχει επιλυθεί. Στην πραγματικότητα ονομάζουμε αυτά τα μοτίβα: μοτίβα σχεδιασμού.

Υπάρχουν 3 κατηγορίες μοτίβων σχεδιασμού: δημιουργική , δομική και συμπεριφορά .

Δημιουργική

Τα δημιουργικά μοτίβα είναι μοτίβα που ελέγχουν τον τρόπο δημιουργίας αντικειμένων.

Παραδείγματα δημιουργικών μοτίβων περιλαμβάνουν:

  • Το μοτίβο Singleton , για τη διασφάλιση μόνο μιας παρουσίας μιας τάξης μπορεί να υπάρχει
  • Το μοτίβο Abstract Factory , για τη δημιουργία μιας παρουσίας πολλών οικογενειών τάξεων
  • Το μοτίβο πρωτοτύπου , για να ξεκινήσετε με μια παρουσία που είναι κλωνοποιημένη από μια υπάρχουσα

Κατασκευαστικός

Τα δομικά μοτίβα είναι μοτίβα που απλοποιούν τον τρόπο με τον οποίο καθορίζουμε τις σχέσεις μεταξύ των συστατικών.

Παραδείγματα δομικών σχεδίων είναι:

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

Συμπεριφορική

Τα πρότυπα συμπεριφοράς είναι κοινά πρότυπα για τη διευκόλυνση της κομψής επικοινωνίας μεταξύ αντικειμένων.

Παραδείγματα συμπεριφορών είναι:

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

Κριτικές μοτίβου σχεδιασμού

Τα σχέδια σχεδίασης είναι υπέροχα και όλα, αλλά μερικές φορές μπορούν να προσθέσουν μια επιπλέον πολυπλοκότητα στα σχέδιά μας. Είναι σημαντικό να θυμάστε το YAGNI και να προσπαθήσετε να διατηρήσετε τα σχέδιά μας όσο το δυνατόν πιο απλά. Χρησιμοποιείτε μοτίβα σχεδίασης μόνο όταν είστε πραγματικά σίγουροι ότι τα χρειάζεστε. Θα ξέρετε πότε θα το κάνετε.

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

Ο λόγος πίσω από αυτό είναι επειδή τα αρχιτεκτονικά μοτίβα είναι απλώς μοτίβα σχεδιασμού που αυξάνονται σε κλίμακα έως το υψηλό επίπεδο , όπου τα μοτίβα σχεδιασμού είναι υλοποιήσεις χαμηλού επιπέδου (πιο κοντά σε τάξεις και λειτουργίες).

Πόροι

Refactoring Guru - Σχέδια σχεδίων

Στάδιο 6: Αρχιτεκτονικές αρχές

Τώρα βρισκόμαστε σε υψηλότερο επίπεδο σκέψης πέρα ​​από το επίπεδο της τάξης.

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

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

Εδώ θα συνιστούσα να μάθετε αμέσως από το ρόπαλο:

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

Ο θείος Μπομπ ανακάλυψε και αρχικά τεκμηρίωσε πολλές από αυτές τις αρχές, οπότε ο καλύτερος πόρος για να μάθετε για αυτό είναι και πάλι, "Clean Architecture"

Στάδιο 7: Αρχιτεκτονικά στυλ

Η αρχιτεκτονική αφορά τα πράγματα που έχουν σημασία.

Πρόκειται για τον προσδιορισμό του τι χρειάζεται ένα σύστημα για να είναι επιτυχές και, στη συνέχεια, στοίβαγμα των πιθανοτήτων επιτυχίας επιλέγοντας την αρχιτεκτονική που ταιριάζει καλύτερα στις απαιτήσεις.

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

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

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

Δομικά

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

Ακολουθούν μερικά παραδείγματα:

  • Οι αρχιτεκτονικές που βασίζονται σε στοιχεία υπογραμμίζουν τον διαχωρισμό των ανησυχιών μεταξύ των επιμέρους στοιχείων ενός συστήματος. Σκεφτείτε το Google για ένα δευτερόλεπτο. Σκεφτείτε πόσες εφαρμογές έχουν στην επιχείρησή τους (Έγγραφα Google, Google Drive, Χάρτες Google κ.λπ.). Για πλατφόρμες με πολλές λειτουργίες, οι αρχιτεκτονικές που βασίζονται σε συστατικά χωρίζουν τις ανησυχίες σε ανεξάρτητα συστατικά που συνδέονται χαλαρά. Αυτό είναι οριζόντιος διαχωρισμός.
  • Μονολιθικό σημαίνει ότι η εφαρμογή συνδυάζεται σε μια ενιαία πλατφόρμα ή πρόγραμμα, που αναπτύσσεται συνολικά. Σημείωση: Μπορείτε να έχετε μια μονολιθική αρχιτεκτονική ΚΑΙ βασισμένη σε στοιχεία, εάν διαχωρίζετε σωστά τις εφαρμογές σας, αλλά αναπτύξτε τις όλες ως ένα κομμάτι .
  • Οι πολυεπίπεδες αρχιτεκτονικές διαχωρίζουν τις ανησυχίες κάθετα περικόπτοντας λογισμικό σε επίπεδα υποδομής, εφαρμογών και τομέα.

Καθαρή αρχιτεκτονική

Ένα παράδειγμα περικοπής των ανησυχιών μιας εφαρμογής κάθετα χρησιμοποιώντας μια πολυεπίπεδη αρχιτεκτονική. Διαβάστε εδώ για περισσότερες πληροφορίες σχετικά με το πώς να το κάνετε αυτό.

Μηνύματα

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

Ακολουθούν μερικά παραδείγματα αρχιτεκτονικών στυλ που βασίζονται σε μηνύματα:

  • Οι αρχιτεκτονικές βάσει συμβάντων προβάλλουν όλες τις σημαντικές αλλαγές στην κατάσταση ως συμβάντα. Για παράδειγμα, σε μια εφαρμογή διαπραγμάτευσης βινυλίου, η κατάσταση μιας προσφοράς ενδέχεται να αλλάξει από "σε εκκρεμότητα" σε "αποδεκτή" όταν και τα δύο μέρη συμφωνούν για το εμπόριο.
  • Δημοσιεύστε-εγγραφείτε αρχιτεκτονικές που βασίζονται στο σχέδιο του Observer, καθιστώντας την την κύρια μέθοδο επικοινωνίας μεταξύ του ίδιου του συστήματος, των τελικών χρηστών / πελατών και άλλων συστημάτων και στοιχείων.

Διανέμονται

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

Μερικά παραδείγματα κατανεμημένων αρχιτεκτονικών στυλ είναι:

  • Αρχιτεκτονική διακομιστή-πελάτη . Μία από τις πιο κοινές αρχιτεκτονικές, όπου διαιρούμε την εργασία που πρέπει να γίνει μεταξύ του πελάτη (παρουσίαση) και του διακομιστή (επιχειρηματική λογική).
  • Οι αρχιτεκτονικές peer-to-peer διανέμουν εργασίες επιπέδου εφαρμογής μεταξύ εξίσου προνομιούχων συμμετεχόντων, δημιουργώντας ένα δίκτυο peer-to-peer.

Στάδιο 8: Αρχιτεκτονικά μοτίβα

Τα αρχιτεκτονικά μοτίβα εξηγούν με μεγαλύτερη τακτική λεπτομέρεια τον τρόπο υλοποίησης ενός από αυτά τα αρχιτεκτονικά στυλ .

Ακολουθούν μερικά παραδείγματα αρχιτεκτονικών προτύπων και στυλ που κληρονομούν:

  • Το Domain-Driven Design είναι μια προσέγγιση στην ανάπτυξη λογισμικού έναντι πολύπλοκων τομέων με προβλήματα. Για να είναι το DDD πιο επιτυχημένο, πρέπει να εφαρμόσουμε μια πολυεπίπεδη αρχιτεκτονική για να διαχωρίσουμε τις ανησυχίες ενός μοντέλου τομέα από τις λεπτομέρειες υποδομής που κάνουν την εφαρμογή να λειτουργεί πραγματικά, όπως βάσεις δεδομένων, διακομιστές ιστού, κρυφές μνήμες κ.λπ.
  • Το Model-View Controller είναι ίσως το πιο γνωστό αρχιτεκτονικό μοτίβο για την ανάπτυξη εφαρμογών που βασίζονται σε διεπαφή χρήστη. Λειτουργεί χωρίζοντας την εφαρμογή σε 3 στοιχεία: μοντέλο, προβολή και ελεγκτή. Το MVC είναι απίστευτα χρήσιμο όταν ξεκινάτε για πρώτη φορά και σας βοηθάει να σκεφτείτε άλλες αρχιτεκτονικές, αλλά υπάρχει ένα σημείο που συνειδητοποιούμε ότι το MVC δεν είναι αρκετό για προβλήματα με πολλή επιχειρηματική λογική.
  • Η προμήθεια συμβάντων είναι μια λειτουργική προσέγγιση όπου αποθηκεύουμε μόνο τις συναλλαγές και ποτέ την πολιτεία. Εάν χρειαζόμαστε ποτέ το κράτος, μπορούμε να εφαρμόσουμε όλες τις συναλλαγές από την αρχή του χρόνου.

Στάδιο 9: Επιχειρηματικά πρότυπα

Κάθε αρχιτεκτονικό μοτίβο που θα επιλέξετε θα εισαγάγει μια σειρά κατασκευών και τεχνικής ορολογίας για να εξοικειωθείτε και να αποφασίσετε αν αξίζει τον κόπο να χρησιμοποιήσετε ή όχι.

Λαμβάνοντας ένα παράδειγμα που πολλοί από εμάς γνωρίζουμε, στο MVC , η προβολή διατηρεί όλο τον κώδικα επιπέδου παρουσίασης, ο ελεγκτής μεταφράζει εντολές και ερωτήματα από την προβολή σε αιτήματα που χειρίζονται το μοντέλο και επιστρέφονται από τον ελεγκτή .

Πού στο μοντέλο (M) χειριζόμαστε αυτά τα πράγματα ;:

  • λογική επικύρωσης
  • αμετάβλητοι κανόνες
  • συμβάντα τομέα
  • περιπτώσεις χρήσης
  • σύνθετα ερωτήματα
  • και επιχειρηματική λογική

Εάν απλώς χρησιμοποιούμε ένα ORM (αντικείμενο-σχεσιακός χαρτογράφος) όπως το Sequelize ή το TypeORM ως μοντέλο , όλα αυτά τα σημαντικά πράγματα πρέπει να αφήσουν να ερμηνευτούν στο πού πρέπει να πάει και βρίσκεται σε κάποιο απροσδιόριστο επίπεδο μεταξύ (τι πρέπει να είναι πλούσιο) ) μοντέλο και τον ελεγκτή .

mvc-2

Λήφθηκε από τα μοντέλα "3.1 - Λεπτά (χωρίς λογική)" στο solidbook.io.

Αν υπάρχει κάτι που έχω μάθει μέχρι στιγμής στο ταξίδι μου πέρα ​​από το MVC, είναι ότι υπάρχει μια κατασκευή για τα πάντα .

Για καθένα από αυτά τα πράγματα που το MVC δεν μπορεί να αντιμετωπίσει, υπάρχουν άλλα επιχειρηματικά πρότυπα για την επίλυσή τους. Για παράδειγμα:

  • Οι οντότητες περιγράφουν μοντέλα που έχουν ταυτότητα.
  • Τα Value Objects είναι μοντέλα που δεν έχουν ταυτότητα και μπορούν να χρησιμοποιηθούν για να ενσωματωθεί η λογική επικύρωσης.
  • Το Domain Events είναι συμβάντα που δηλώνουν κάποια σχετική επιχειρηματική εκδήλωση που λαμβάνει χώρα και μπορούν να εγγραφούν από άλλα στοιχεία.

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

Σχέδια ολοκλήρωσης

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

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

Ο σχεδιασμός ενός συστήματος κλίμακας μπορεί να είναι απίστευτα προκλητικός. Απαιτεί μια βαθιά κατανόηση των περιορισμών κάθε στοιχείου στην αρχιτεκτονική και ένα σχέδιο δράσης για το πώς να μετριάσετε το άγχος στην αρχιτεκτονική σας και να συνεχίσετε να εξυπηρετείτε αιτήματα σε καταστάσεις υψηλής κυκλοφορίας.

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

Αυτό μπορεί να είναι δύσκολο να εφαρμοστεί, αλλά οι κοινές αρχιτεκτονικές καταλήγουν να βασίζονται σε συμβάντα και να βασίζονται σε ένα ευρύ φάσμα λογισμικού και σχεδιαστικών εννοιών, αρχών και πρακτικών όπως Event Storming, DDD, CQRS (διαχωρισμός απόκρισης ερωτημάτων εντολών) και Event Sourcing .

Ελπίζω να σας ήταν χρήσιμο!

Ενημερώστε με εάν έχετε οποιεσδήποτε προτάσεις ή ερωτήσεις.

Στην υγειά σας!

Περάστε το στο GitHub

Διαβάστε το βιβλίο για το σχεδιασμό και την αρχιτεκτονική λογισμικού

Διαβάστε την εγγραφή

khalilstemmler.com - Διδάσκω τις βέλτιστες πρακτικές Advanced TypeScript & Node.js για εφαρμογές μεγάλης κλίμακας και πώς να γράφω ευέλικτο, διατηρήσιμο λογισμικό.