Această postare a fost editată ultima dată de Summer la 27-09-2017, 15:32
Acest articol este o povestire scurtă care imită întrebările și răspunsurile, iar autorul folosește un stil umoristic pentru a analiza pe scurt munca arhitecților: Vreau să fiu arhitect software. Aceasta este o opțiune excelentă pentru tinerii dezvoltatori software. Vreau să conduc echipa și să iau decizii importante despre baze de date și framework-uri, servere web etc. Ah, atunci nu vrei deloc să fii arhitect software. Desigur că am vrut să fiu luătoarea deciziilor importante. E în regulă, dar nu incluzi deciziile importante în listă, care sunt decizii irelevante. Ce vrei să spui? Spui că bazele de date nu sunt decizii importante, știi cât cheltuim pe ele? Poate costă prea mult. Totuși, bazele de date nu sunt una dintre deciziile importante. Cum poți spune asta? Baza de date este nucleul sistemului, unde toate datele sunt sistematizate, clasificate, indexate și accesate. Fără o bază de date, nu ar exista sistem. Baza de date este doar un dispozitiv IO care oferă unele instrumente utile pentru clasificare, interogare și raportare a informațiilor, dar acestea sunt doar funcții auxiliare ale arhitecturii sistemului. Ajutor? Este revoltător. Așa este, e auxiliar. Regulile de afaceri ale sistemului pot profita de unele dintre aceste unelte, dar aceste instrumente nu sunt inerente regulilor de afaceri corespunzătoare. Dacă este nevoie, poți înlocui cele existente cu alte unelte; Și regulile de afaceri nu se vor schimba. Ei bine, da, dar a trebuit să fie recodificat, pentru că aceste unelte erau folosite în baza de date originală. Asta e problema ta. Ce vrei să spui? Problema ta este că crezi că regulile de business depind de unelte de baze de date, dar nu sunt așa. Sau cel puțin, nu ar trebui să fie așa până nu se oferă o arhitectură bună. E pur și simplu nebunie. Cum creezi reguli de business care să nu folosească aceste instrumente? Nu spun că nu folosesc instrumente de bază de date, dar nu depind de ele. Regulile de afaceri nu trebuie să știe ce bază de date folosești. Deci, cum obții reguli de business fără să știi ce unelte să folosești? Inversează dependențele astfel încât baza de date să depindă de regulile de business. Asigură-te că regulile de afaceri nu depind de baza de date. Vorbești prostii. Din contră, folosesc limbajul arhitecturii software. Acesta este principiul inversiunii dependenței: standardele de nivel scăzut ar trebui să se bazeze pe standarde de nivel înalt. Prostii! Criterii de nivel înalt (presupunând că se referă la reguli de business) Apelarea criteriilor de nivel inferior (presupunând că se referă la baze de date). Prin urmare, criteriul de nivel înalt se va baza pe criteriul de nivel inferior, conform principiului că apelantul depinde de cel care a apelat. Toată lumea știe asta! Acest lucru este valabil la rulare. Dar când compilăm, ceea ce vrem este inversiunea dependenței. Codul sursă al ghidurilor de nivel înalt nu ar trebui să menționeze codul sursă al ghidurilor de nivel inferior. Hai! Cum poți face un apel fără să menționezi? Desigur, nicio problemă. Asta implică orientarea pe obiecte. Orientarea pe obiecte se referă la crearea de modele în lumea reală, combinând date, funcționalitate și obiecte coerente. Este vorba despre organizarea codului într-o structură intuitivă. Așa se spune? După cum știm cu toții, acesta este adevărul evident. Da, este, însă atunci când folosești ghiduri orientate pe obiecte, este într-adevăr posibil să invoci fără să le menționezi. Ei bine, cum se face asta? În designul orientat pe obiecte, obiectele trimit mesaje între ele. Așa este, desigur. Când un expeditor trimite un mesaj, nu știe tipul de destinatar. Depinde de limbajul folosit. În Java, emițătorul cunoaște cel puțin tipul de bază al receptorului. În Ruby, cel puțin expeditorul știe că receptorul este capabil să gestioneze mesajele primite. Așa este. Totuși, în orice caz, expeditorul nu cunoaște tipul specific de receptor. Așa este, ei bine, așa este. Prin urmare, un emițător poate proiecta un receptor care să îndeplinească o funcție fără a menționa tipul specific de receptor. Așa e, așa e. Înţeleg. Totuși, emițătorul depinde în continuare de destinatar. Acest lucru este valabil la rulare. Totuși, este diferit când este compilat. Codul sursă al emițătorului nu menționează și nu depinde de codul sursă al receptorului. De fapt, codul sursă al destinatarului depinde de codul sursă al emițătorului. În niciun caz! Expeditorul depinde în continuare de clasa pe care o trimite. Poate dintr-un cod sursă va fi mai clar. Paragraful următor este scris în Java. Primul este expeditorul: expeditor de colete; public class Sender { private Receiver receiver; public Sender (Receiver r) { receiver = r; } public void doSomething () { receiver.receiveThis (); } interfață publică Receiver { void receiveThis (); } }Iată receptorul: receptor de pachet; Importă expeditorul. Expeditor; clasa publică SpecificReceiver implementează Sender.Receiver { public void receiveThis () { //face ceva interesant. } }Notă: Receptorul depinde de expeditor, Receptorul Specific depinde de expeditor și nu există informații legate de receptor în expeditor. Da, dar minți, ai pus interfața destinatarului în clasa emițător. Începi să înțelegi. Ce știi tu? Desigur, este principiul arhitecturii. Expeditorul are interfața pe care receptorul trebuie să o implementeze. Dacă asta înseamnă că trebuie să folosesc clase imbricate, atunci ...... Clasele imbricate sunt doar unul dintre mijloacele pentru un scop, există și alte moduri. Stai puțin. Ce legătură are asta cu bazele de date? Am început să vorbim despre baze de date. Să aruncăm o privire mai atentă la cod. Prima este o regulă simplă de afaceri: pachete businessRules; importă entități. Ceva; clasa publică BusinessRule { gateway privat BusinessRuleGateway; public BusinessRule (BusinessRuleGateway gateway) { this.gateway = gateway; } public void execute (String id) { gateway.startTransaction (); Something thing = gateway.getSomething (id); thing.makeChanges (); gateway.saveSomething (thing); gateway.endTransaction (); } }Regulile de afaceri nu au prea multă greutate. Acesta este doar un exemplu. Ar putea exista mai multe astfel de clase care implementează multe reguli de business diferite. Bine, deci ce este exact Gateway? Oferă toate metodele de acces la date prin reguli de business. Implementează-l astfel: pachete businessRules; importă entități. Ceva; interfață publică BusinessRuleGateway { Something getSomething (String id); void startTransaction (); void saveSomething (Something thing); void endTransaction (); }Notă: Aceasta este în businessRules. Bine, ce este clasa Ceva? Reprezintă un obiect de afaceri simplu. Îl pun în entități. entități de pachet; clasa publică Ceva { public void makeChanges () { //... } }În cele din urmă, implementarea BusinessRuleGateway, această clasă cunoaște adevărata bază de date: baza de date a pachetelor; import businessRules.BusinessRuleGateway; importă entități. Ceva; clasa publică MySqlBusinessRuleGateway implementează BusinessRuleGateway { public Something getSomething (String id) { // folosește MySQL pentru a obține un lucru. } public void startTransaction () { // start MySql transaction } public void saveSomething (Something thing) { // save thing in MySql } public void endTransaction () { // end Tranzacție MySQL } }În plus, rețineți că regulile de afaceri apelează baza de date la rulare; Totuși, la compilare, baza de date implică și depinde de businessRules. Ei bine, cred că am înțeles. Folosești doar polimorfismul pentru a ascunde faptul că baza de date este implementată de regulile de business. Totuși, este încă necesară o interfață pentru a furniza toate uneltele bazei de date regulilor de business. Nu, deloc. Nu am încercat să oferim instrumente de bază de date regulilor de business. În schimb, folosesc reguli de business pentru a crea interfețe adaptate nevoilor lor. Implementarea acestor interfețe îți permite să apelezi la uneltele potrivite. Da, dar dacă trebuie să folosești toate uneltele pentru toate regulile de business, atunci pur și simplu pune unealta în interfața gateway-ului. Ah, nu cred că încă înțelegi. Să înțelegi ce? Este deja clar. Fiecare regulă de business definește o singură interfață pentru instrumentele de acces la date de care are nevoie. Stai puțin, ce zici? Acesta este Principiul Segregării Interfeței. Fiecare clasă de reguli de afaceri folosește doar anumite facilități ale bazei de date. Prin urmare, interfețele oferite de fiecare regulă de business pot accesa doar facilitățile corespunzătoare. Totuși, acest lucru înseamnă că există multe interfețe și multe clase mici de implementare care apelează la alte clase de baze de date. Minunat, începi să înțelegi. Dar e prea dezordonat și o pierdere de timp. De ce să faci asta? Acest lucru este organizat și economisește timp. Hai, adună mult cod de dragul codului. Din contră, deciziile irelevante pot fi amânate prin decizii arhitecturale importante. Ce înseamnă aceasta? Îmi amintesc că la început ai spus că vrei să fii arhitect software, nu-i așa? Vrei să iei toate deciziile care contează cu adevărat. Da, asta am crezut și eu. Vrei să iei decizii despre baze de date, servere web și framework-uri, nu-i așa? Da, spui că nimic din toate astea nu contează. Doar conținut irelevant. Așa este. Atât. Deciziile importante luate de arhitecții software sunt cele care îți permit să iei decizii despre baze de date, servere web și framework-uri. Dar trebuie să decizi care sunt mai întâi! Nu, nu funcționează. De fapt, acestea pot fi decise mai târziu în ciclul de dezvoltare, când informația este mai abundentă. Este un dezastru dacă arhitecții identifică cadrele din timp doar pentru a descoperi că acestea nu oferă performanța necesară sau introduc constrângeri intolerabile. Doar când arhitectul decide să amâne decizia va lua o decizie atunci când informația este suficientă; Echipele care nu folosesc dispozitive și framework-uri IO lente și consumatoare de resurse pot crea medii de testare rapide și ușoare la discreția arhitecților. Doar arhitecții săi se preocupă de ceea ce contează cu adevărat și îi întârzie pe cei care nu contează, iar o astfel de echipă este norocosa. Prostii, nu înțeleg deloc ce vrei să spui. Ei bine, aruncă o privire atentă la acest articol, altfel va trebui să aștepți încă 10 ani ca să-l înțelegi.
| 
Postat pe 27.09.2017 15:29:46
|
|
|
Postat pe 28.09.2017 15:00:37
|
Proprietarul|
Postat pe 29.09.2017 08:34:23
|
Postat pe 27.11.2018 11:12:17
|
