Αυτό το άρθρο τροποποιήθηκε τελευταία φορά από το χρήστη Summer στις 2017-9-27 15:32
Αυτό το άρθρο είναι μια σύντομη ιστορία που μιμείται τις ερωτήσεις και απαντήσεις και ο συγγραφέας χρησιμοποιεί ένα χιουμοριστικό ύφος για να αναλύσει εν συντομία τη δουλειά που κάνουν οι αρχιτέκτονες: Θέλω να γίνω αρχιτέκτονας λογισμικού. Αυτή είναι μια εξαιρετική επιλογή για νέους προγραμματιστές λογισμικού. Θέλω να ηγηθώ της ομάδας και να πάρω σημαντικές αποφάσεις σχετικά με βάσεις δεδομένων και πλαίσια, διακομιστές ιστού κ.λπ. Α, τότε δεν θέλεις καθόλου να γίνεις αρχιτέκτονας λογισμικού. Φυσικά ήθελα να είμαι ο δημιουργός σημαντικών αποφάσεων. Δεν πειράζει, αλλά δεν συμπεριλαμβάνετε σημαντικές αποφάσεις στη λίστα σας, οι οποίες είναι άσχετες αποφάσεις. Τι εννοείς? Λέτε ότι οι βάσεις δεδομένων δεν είναι σημαντικές αποφάσεις, ξέρετε πόσα ξοδεύουμε για αυτές; Ίσως κοστίζει πάρα πολύ. Ωστόσο, οι βάσεις δεδομένων δεν είναι μία από τις σημαντικές αποφάσεις. Πώς μπορείς να το πεις αυτό; Η βάση δεδομένων είναι ο πυρήνας του συστήματος, όπου όλα τα δεδομένα συστηματοποιούνται, ταξινομούνται, ευρετηριάζονται και προσπελάζονται. Χωρίς βάση δεδομένων, δεν θα υπήρχε σύστημα. Η βάση δεδομένων είναι απλώς μια συσκευή IO που τυχαίνει να παρέχει μερικά χρήσιμα εργαλεία για ταξινόμηση, αναζήτηση και αναφορά πληροφοριών, αλλά αυτές είναι μόνο βοηθητικές λειτουργίες της αρχιτεκτονικής του συστήματος. Βοήθεια? Αυτό είναι εξωφρενικό. Σωστά, είναι βοηθητικό. Οι επιχειρησιακοί κανόνες του συστήματος μπορεί να είναι σε θέση να επωφεληθούν από ορισμένα από αυτά τα εργαλεία, αλλά αυτά τα εργαλεία δεν είναι εγγενή στους αντίστοιχους επιχειρηματικούς κανόνες. Εάν χρειάζεται, μπορείτε να αντικαταστήσετε τα υπάρχοντα με διαφορετικά εργαλεία. Και οι επιχειρηματικοί κανόνες δεν θα αλλάξουν. Λοιπόν, ναι, αλλά έπρεπε να επανακωδικοποιηθεί, επειδή αυτά τα εργαλεία χρησιμοποιήθηκαν στην αρχική βάση δεδομένων. Αυτό είναι το πρόβλημά σου. Τι εννοείς? Το πρόβλημά σας είναι ότι πιστεύετε ότι οι επιχειρηματικοί κανόνες εξαρτώνται από τα εργαλεία της βάσης δεδομένων, αλλά δεν είναι. Ή τουλάχιστον, δεν θα έπρεπε να είναι έτσι μέχρι να παρασχεθεί μια καλή αρχιτεκτονική. Είναι απλά τρελό. Πώς δημιουργείτε επιχειρηματικούς κανόνες που δεν χρησιμοποιούν αυτά τα εργαλεία; Δεν λέω ότι δεν χρησιμοποιούν εργαλεία βάσης δεδομένων, αλλά δεν εξαρτώνται από αυτό. Οι επιχειρηματικοί κανόνες δεν χρειάζεται να γνωρίζουν ποια βάση δεδομένων χρησιμοποιείτε. Πώς λοιπόν αποκτάτε επιχειρηματικούς κανόνες χωρίς να γνωρίζετε ποια εργαλεία να χρησιμοποιήσετε; Αντιστρέψτε τις εξαρτήσεις έτσι ώστε η βάση δεδομένων να εξαρτάται από επιχειρηματικούς κανόνες. Βεβαιωθείτε ότι οι επιχειρηματικοί κανόνες δεν εξαρτώνται από τη βάση δεδομένων. Λες ανοησίες. Αντίθετα, χρησιμοποιώ τη γλώσσα της αρχιτεκτονικής λογισμικού. Αυτή είναι η αρχή της αντιστροφής της εξάρτησης: τα πρότυπα χαμηλού επιπέδου πρέπει να βασίζονται σε πρότυπα υψηλού επιπέδου. Ανοησίες! Κριτήρια υψηλού επιπέδου (με την παραδοχή ότι αναφέρονται σε επιχειρηματικούς κανόνες) Κλήση κριτηρίων χαμηλού επιπέδου (με την παραδοχή ότι αναφέρονται σε βάσεις δεδομένων). Επομένως, το κριτήριο υψηλού επιπέδου θα βασίζεται στο κριτήριο χαμηλού επιπέδου σύμφωνα με την αρχή ότι ο καλών εξαρτάται από τον καλούμενο. Όλοι το ξέρουν αυτό! Αυτό ισχύει κατά το χρόνο εκτέλεσης. Αλλά κατά τη μεταγλώττιση, αυτό που θέλουμε είναι η αντιστροφή εξάρτησης. Ο πηγαίος κώδικας των κατευθυντήριων γραμμών υψηλού επιπέδου δεν πρέπει να αναφέρει τον πηγαίο κώδικα των κατευθυντήριων γραμμών χαμηλού επιπέδου. Έλα! Πώς μπορείτε να πραγματοποιήσετε μια κλήση χωρίς να το αναφέρετε; Φυσικά κανένα πρόβλημα. Αυτό είναι το αντικειμενοστραφή. Ο αντικειμενοστραφής αφορά τη δημιουργία μοντέλων πραγματικού κόσμου, συνδυάζοντας δεδομένα, λειτουργικότητα και συνεκτικά αντικείμενα. Πρόκειται για την οργάνωση του κώδικα σε μια διαισθητική δομή. Αυτό λένε; Όπως όλοι γνωρίζουμε, αυτή είναι η προφανής αλήθεια. Ναι, είναι, ωστόσο, όταν χρησιμοποιείτε αντικειμενοστρεφείς οδηγίες, είναι πράγματι δυνατό να το επικαλεστείτε χωρίς να το αναφέρετε. Λοιπόν, πώς να το κάνουμε αυτό; Στην αντικειμενοστραφή σχεδίαση, τα αντικείμενα στέλνουν μηνύματα το ένα στο άλλο. Αυτό είναι σωστό, φυσικά. Όταν ένας αποστολέας στέλνει ένα μήνυμα, δεν γνωρίζει τον τύπο του παραλήπτη. Εξαρτάται από τη γλώσσα που χρησιμοποιείται. Στην Java, ο αποστολέας γνωρίζει τουλάχιστον τον βασικό τύπο του παραλήπτη. Στο Ruby, ο αποστολέας γνωρίζει τουλάχιστον ότι ο παραλήπτης είναι σε θέση να χειριστεί τα μηνύματα που λαμβάνει. Σωστά. Σε κάθε περίπτωση, όμως, ο αποστολέας δεν γνωρίζει τον συγκεκριμένο τύπο παραλήπτη. Σωστά, λοιπόν, είναι. Επομένως, ένας αποστολέας μπορεί να σχεδιάσει έναν δέκτη για να εκτελεί μια λειτουργία χωρίς να αναφέρει τον συγκεκριμένο τύπο δέκτη. Σωστά, σωστά. Καταλαβαίνω. Ωστόσο, ο αποστολέας εξακολουθεί να εξαρτάται από τον παραλήπτη. Αυτό ισχύει κατά το χρόνο εκτέλεσης. Ωστόσο, είναι διαφορετικό όταν μεταγλωττίζεται. Ο πηγαίος κώδικας του αποστολέα δεν αναφέρει ούτε εξαρτάται από τον πηγαίο κώδικα του παραλήπτη. Στην πραγματικότητα, ο πηγαίος κώδικας του παραλήπτη εξαρτάται από τον πηγαίο κώδικα του αποστολέα. Με κανέναν τρόπο! Ο αποστολέας εξακολουθεί να εξαρτάται από την κλάση που στέλνει. Ίσως από κάποιο πηγαίο κώδικα, να είναι πιο ξεκάθαρο. Η ακόλουθη παράγραφος είναι γραμμένη σε Java. Πρώτος είναι ο αποστολέας: αποστολέας πακέτου? δημόσια τάξη Αποστολέας { ιδιωτικός δέκτης δέκτης; δημόσιος αποστολέας (Παραλήπτης r) { παραλήπτης = r; } δημόσιο κενό doSomething () { receiver.receiveThis (); } δημόσια διεπαφή Δέκτης { void receiveThis (); } }Εδώ είναι ο δέκτης: δέκτης συσκευασίας? αποστολέας εισαγωγής. Αποστολέας; δημόσια τάξη SpecificReceiver υλοποιεί το Sender.Receiver { public void receiveThis () { //do something interest. } }Σημείωση: Ο παραλήπτης εξαρτάται από τον αποστολέα, ο SpecificReceiver εξαρτάται από τον αποστολέα και δεν υπάρχουν πληροφορίες που σχετίζονται με τον παραλήπτη στον αποστολέα. Ναι, αλλά λέτε ψέματα, βάζετε τη διεπαφή του παραλήπτη στην κλάση αποστολέα. Αρχίζεις να καταλαβαίνεις. Τι γνωρίζετε; Φυσικά, είναι η αρχή της αρχιτεκτονικής. Ο αποστολέας έχει τη διεπαφή που πρέπει να εφαρμόσει ο παραλήπτης. Αν αυτό σημαίνει ότι πρέπει να χρησιμοποιήσω ένθετες, τότε ...... Οι ένθετες είναι μόνο ένα από τα μέσα για έναν σκοπό, υπάρχουν και άλλοι τρόποι. Λοιπόν, περιμένετε ένα λεπτό. Τι σχέση έχει αυτό με τις βάσεις δεδομένων; Αρχίσαμε να μιλάμε για βάσεις δεδομένων. Ας ρίξουμε μια ματιά στον κώδικα λίγο περισσότερο. Ο πρώτος είναι ένας απλός επιχειρηματικός κανόνας: επιχειρησιακοί κανόνες πακέτων· οντότητες εισαγωγής. Κάτι; δημόσια κατηγορία BusinessRule { ιδιωτική πύλη BusinessRuleGateway; public BusinessRule (BusinessRuleGateway gateway) { this.gateway = πύλη; } public void execute (Αναγνωριστικό συμβολοσειράς) { gateway.startTransaction (); Κάτι πράγμα = gateway.getSomething (id); thing.makeChanges (); gateway.saveSomething (πράγμα); gateway.endTransaction (); } }Οι επιχειρηματικοί κανόνες δεν έχουν μεγάλη βαρύτητα. Αυτό είναι μόνο ένα παράδειγμα. Θα μπορούσαν να υπάρχουν περισσότερες τέτοιες τάξεις που εφαρμόζουν πολλούς διαφορετικούς επιχειρηματικούς κανόνες. Εντάξει, τι ακριβώς είναι το Gateway; Παρέχει όλες τις μεθόδους πρόσβασης στα δεδομένα μέσω επιχειρηματικών κανόνων. Εφαρμόστε το ως εξής: επιχειρησιακοί κανόνες πακέτων· οντότητες εισαγωγής. Κάτι; δημόσια διεπαφή BusinessRuleGateway { Something getSomething (Αναγνωριστικό συμβολοσειράς); void startTransaction (); void saveSomething (Κάτι πράγμα); void endTransaction (); }Σημείωση: Αυτό είναι στο businessRules. Εντάξει, τι είναι η κλάση Κάτι; Αντιπροσωπεύει ένα απλό επιχειρηματικό αντικείμενο. Το βάζω σε οντότητες. οντότητες πακέτων· δημόσια τάξη Κάτι { δημόσιο κενό makeChanges () { //... } }Τελικά η υλοποίηση του BusinessRuleGateway, αυτή η κλάση γνωρίζει την πραγματική βάση δεδομένων: βάση δεδομένων πακέτων? εισαγωγή businessRules.BusinessRuleGateway; οντότητες εισαγωγής. Κάτι; δημόσια τάξη MySqlBusinessRuleGateway υλοποιεί το BusinessRuleGateway { public Something getSomething (String id) { // χρησιμοποιήστε MySql για να πάρετε ένα πράγμα. } public void startTransaction () { // start MySql transaction } public void saveSomething (Something thing) { // save thing in MySql } public void endTransaction () { // end Συναλλαγή MySql } }Επιπλέον, σημειώστε ότι οι επιχειρηματικοί κανόνες καλούν τη βάση δεδομένων κατά το χρόνο εκτέλεσης. Ωστόσο, κατά τη στιγμή της μεταγλώττισης, η βάση δεδομένων περιλαμβάνει και εξαρτάται από τους επιχειρηματικούς κανόνες. Λοιπόν, νομίζω ότι το καταλαβαίνω. Απλώς χρησιμοποιείτε πολυμορφισμό για να κρύψετε το γεγονός ότι η βάση δεδομένων υλοποιείται από επιχειρηματικούς κανόνες. Ωστόσο, εξακολουθεί να απαιτείται μια διεπαφή για την παροχή όλων των εργαλείων της βάσης δεδομένων στους επιχειρησιακούς κανόνες. Οχι καθόλου. Δεν προσπαθήσαμε να παρέχουμε εργαλεία βάσης δεδομένων σε επιχειρηματικούς κανόνες. Αντίθετα, χρησιμοποιούν επιχειρηματικούς κανόνες για να δημιουργήσουν διεπαφές για αυτό που χρειάζονται. Η εφαρμογή αυτών των διεπαφών σάς επιτρέπει να καλείτε τα σωστά εργαλεία. Ναι, αλλά εάν πρέπει να χρησιμοποιήσετε κάθε εργαλείο για όλους τους επιχειρηματικούς κανόνες, τότε απλώς τοποθετήστε το εργαλείο στη διεπαφή πύλης. Α, δεν νομίζω ότι καταλαβαίνεις ακόμα. Καταλαβαίνετε τι; Αυτό είναι ήδη σαφές. Κάθε επιχειρηματικός κανόνας ορίζει μόνο μία διεπαφή για τα εργαλεία πρόσβασης δεδομένων που χρειάζεται. Περίμενε ένα λεπτό, τι λες; Αυτή είναι η αρχή του διαχωρισμού διεπαφής. Κάθε κλάση επιχειρηματικού κανόνα χρησιμοποιεί μόνο ορισμένες ευκολίες της βάσης δεδομένων. Επομένως, οι διεπαφές που παρέχονται από κάθε επιχειρηματικό κανόνα μπορούν να έχουν πρόσβαση μόνο στις αντίστοιχες ευκολίες. Ωστόσο, αυτό σημαίνει ότι υπάρχουν πολλές διεπαφές και πολλές μικρές υλοποίησης που καλούν άλλες βάσεων δεδομένων. Τέλεια, αρχίζεις να καταλαβαίνεις. Αλλά είναι πολύ ακατάστατο και χάσιμο χρόνου. Γιατί να το κάνετε αυτό; Αυτό είναι οργανωμένο και εξοικονομεί χρόνο. Έλα, πάρε πολύ κώδικα για χάρη του κώδικα. Αντίθετα, άσχετες αποφάσεις μπορεί να καθυστερήσουν μέσω σημαντικών αρχιτεκτονικών αποφάσεων. Τι σημαίνει αυτό? Θυμάμαι στην αρχή, είπες ότι ήθελες να γίνεις αρχιτέκτονας λογισμικού, έτσι δεν είναι; Θέλετε να πάρετε όλες τις αποφάσεις που έχουν πραγματικά σημασία. Ναι, αυτό σκέφτηκα. Θέλετε να λαμβάνετε αποφάσεις σχετικά με βάσεις δεδομένων, διακομιστές ιστού και πλαίσια, σωστά; Ναι, λέτε ότι τίποτα από αυτά δεν έχει σημασία. Απλά άσχετο περιεχόμενο. Σωστά. Αυτό είναι. Οι σημαντικές αποφάσεις που λαμβάνονται από αρχιτέκτονες λογισμικού είναι αυτές που σας επιτρέπουν να λαμβάνετε αποφάσεις σχετικά με βάσεις δεδομένων, διακομιστές ιστού και πλαίσια. Αλλά πρέπει πρώτα να αποφασίσετε ποια! Όχι, δεν λειτουργεί. Στην πραγματικότητα, αυτά μπορούν να αποφασιστούν αργότερα στον κύκλο ανάπτυξης, όταν οι πληροφορίες είναι πιο άφθονες. Είναι καταστροφή εάν οι αρχιτέκτονες προσδιορίζουν εκ των προτέρων πλαίσια μόνο για να διαπιστώσουν ότι δεν παρέχουν την απαιτούμενη απόδοση ή εισάγουν αφόρητους περιορισμούς. Μόνο όταν ο αρχιτέκτονας αποφασίσει να αναβάλει την απόφαση θα λάβει απόφαση όταν οι πληροφορίες είναι επαρκείς. Οι ομάδες που δεν χρησιμοποιούν αργές και απαιτητικές συσκευές εισόδου/εξόδου και πλαίσια μπορούν να δημιουργήσουν γρήγορα, ελαφριά περιβάλλοντα δοκιμών κατά την κρίση των αρχιτεκτόνων. Μόνο οι αρχιτέκτονές του νοιάζονται για αυτό που πραγματικά έχει σημασία και καθυστερούν αυτούς που δεν έχουν, και μια τέτοια ομάδα είναι η τυχερή. Ανοησίες, δεν καταλαβαίνω καθόλου τι εννοείς. Λοιπόν, ρίξτε μια καλή ματιά σε αυτό το άρθρο, διαφορετικά θα πρέπει να περιμένετε άλλα 10 χρόνια για να το καταλάβετε.
| 
Δημοσιεύτηκε στις 27/9/2017 3:29:46 μ.μ.
|
|
|
Δημοσιεύτηκε στις 28/9/2017 3:00:37 μ.μ.
|
Σπιτονοικοκύρης|
Δημοσιεύτηκε στις 29/9/2017 8:34:23 π.μ.
|
Δημοσιεύτηκε στις 27/11/2018 11:12:17 π.μ.
|
