Tätä julkaisua on viimeksi muokannut Summer 27.9.2017 klo 15:32
Tämä artikkeli on lyhyt tarina, joka jäljittelee Q&A:ta, ja kirjoittaja käyttää humoristista tyyliä analysoidakseen lyhyesti arkkitehtien työtä: Haluan olla ohjelmistoarkkitehti. Tämä on erinomainen vaihtoehto nuorille ohjelmistokehittäjille. Haluan johtaa tiimiä ja tehdä tärkeitä päätöksiä tietokannoista ja kehyksistä, webpalvelimista jne. Ai niin, et halua olla ohjelmistoarkkitehti ollenkaan. Tietenkin halusin olla tärkeiden päätösten tekijä. Se on ihan ok, mutta et sisällytä tärkeitä päätöksiä listallesi, jotka ovat epäolennaisia päätöksiä. Mitä tarkoitat? Sanotko, että tietokannat eivät ole tärkeitä päätöksiä, tiedätkö kuinka paljon niihin käytetään? Ehkä se maksaa liikaa. Tietokannat eivät kuitenkaan ole yksi tärkeistä päätöksistä. Miten voit sanoa niin? Tietokanta on järjestelmän ydin, jossa kaikki data systematisoidaan, luokiteltu, indeksoidaan ja niihin päästään käsiksi. Ilman tietokantaa järjestelmää ei olisi. Tietokanta on vain IO-laite, joka sattuu tarjoamaan hyödyllisiä työkaluja luokitteluun, kyselyihin ja tiedon raportointiin, mutta nämä ovat vain järjestelmäarkkitehtuurin aputoimintoja. Apua? Tämä on pöyristyttävää. Niinpä, se on apuväline. Järjestelmän liiketoimintasäännöt saattavat hyödyntää joitakin näistä työkaluista, mutta ne eivät ole olennaisia vastaaviin liiketoimintasääntöihin. Tarvittaessa voit korvata olemassa olevat eri työkaluilla; Ja liiketoimintasäännöt eivät muutu. No, kyllä, mutta se piti koodata uudelleen, koska näitä työkaluja käytettiin alkuperäisessä tietokannassa. Siinä on sinun ongelmasi. Mitä tarkoitat? Ongelmasi on, että luulet liiketoimintasääntöjen riippuvan tietokantatyökaluista, mutta ne eivät ole. Tai ainakin, näin ei pitäisi olla ennen kuin hyvä arkkitehtuuri on tarjottu. Se on ihan hullua. Miten luot liiketoimintasääntöjä, jotka eivät käytä näitä työkaluja? En sano, etteivät he käyttäisi tietokantatyökaluja, mutta he eivät ole riippuvaisia niistä. Liiketoimintasääntöjen ei tarvitse tietää, mitä tietokantaa käytät. Miten siis saa liiketoimintasäännöt tietämättä, mitä työkaluja käyttää? Käännä riippuvuudet niin, että tietokanta riippuu liiketoimintasäännöistä. Varmista, etteivät liiketoimintasäännöt ole riippuvaisia tietokannasta. Puhut hölynpölyä. Päinvastoin, käytän ohjelmistoarkkitehtuurin kieltä. Tämä on riippuvuuden kääntämisen periaate: matalan tason standardien tulisi perustua korkean tason standardeihin. Höpö höpö! Korkean tason kriteerit (olettaen, että viitataan liiketoimintasääntöihin) Matalan tason kriteerien kutsuminen (olettaen, että viitataan tietokantoihin). Siksi korkean tason kriteeri perustuu matalan tason kriteeriin periaatteella, että soittaja on riippuvainen soittajasta. Kaikki tietävät tämän! Tämä pätee ajonaikaisesti. Mutta kääntäessä haluamme riippuvuuden käänteisin. Korkean tason ohjeiden lähdekoodissa ei tulisi mainita matalan tason ohjeiden lähdekoodia. Älä viitsi! Miten voit soittaa mainitsematta sitä? Tietenkään ei ongelmaa. Siinä on olio-orientoituminen. Olioorientaatio tarkoittaa todellisen maailman mallien luomista, datan, toiminnallisuuden ja yhtenäisten objektien yhdistämistä. Kyse on koodin järjestämisestä intuitiiviseksi rakenteeksi. Niin he sanovat? Kuten kaikki tiedämme, tämä on ilmeinen totuus. Kyllä, se on, mutta kun käytetään olio-orientoituja ohjeita, on tosiaan mahdollista kutsua ilman, että siitä puhutaan. No, miten se tehdään? Oliopohjaisessa suunnittelussa objektit lähettävät viestejä toisilleen. Niin on, tietenkin. Kun lähettäjä lähettää viestin, se ei tiedä vastaanottajan tyyppiä. Se riippuu käytetystä kielestä. Javassa lähettäjä tietää ainakin vastaanottajan perustyypin. Rubyssa lähettäjä ainakin tietää, että vastaanotin pystyy käsittelemään vastaanotetut viestit. Niin juuri. Joka tapauksessa lähettäjä ei tiedä tarkkaa vastaanottimen tyyppiä. Niin juuri, no, on. Näin ollen lähettäjä voi suunnitella vastaanottimen suorittamaan toiminnon mainitsematta tarkkaa vastaanotintyyppiä. Niin juuri, juuri niin. Ymmärrän. Lähettäjä riippuu kuitenkin edelleen vastaanottajasta. Tämä pätee ajonaikaisesti. Kuitenkin käännettäessä se on erilainen. Lähettäjän lähdekoodi ei mainitse eikä riipu vastaanottajan lähdekoodista. Itse asiassa vastaanottajan lähdekoodi riippuu lähettäjän lähdekoodista. Ei käy! Lähettäjä riippuu edelleen lähettämästä luokasta. Ehkä jostain lähdekoodista se on selkeämpää. Seuraava kappale on kirjoitettu Javalla. Ensimmäisenä lähettäjä: pakettien lähettäjä; julkinen luokan lähettäjä { yksityinen vastaanottaja; julkinen lähettäjä (vastaanottaja r) { vastaanottaja = r; } julkinen void doSomething () { receiver.receiveThis (); } julkinen käyttöliittymä Vastaanottaja { void receiveThis (); } }Tässä on vastaanottaja: pakettivastaanotin; Tuo lähettäjä. Lähettäjä; public class SpecificReceiver toteuttaa Sender.Receiver { public void receiveThis () { //do jotain mielenkiintoista. } }Huomautus: Vastaanotin riippuu lähettäjästä, SpecificReceiver riippuu lähettäjästä, eikä lähettäjässä ole vastaanottajaan liittyvää tietoa. Kyllä, mutta valehtelet, laitoit vastaanottajan käyttöliittymän lähettäjäluokkaan. Alat ymmärtää. Mitä sinä tiedät? Tietenkin se on arkkitehtuurin periaate. Lähettäjällä on rajapinta, jonka vastaanottajan on toteutettava. Jos se tarkoittaa, että minun täytyy käyttää sisäkkäisiä luokkia, niin ...... Sisäkkäiset luokat ovat vain yksi keino päämäärään, on muitakin tapoja. No, odota hetki. Mitä tekemistä tällä on tietokantojen kanssa? Aloimme puhua tietokannoista. Katsotaanpa koodia vielä vähän. Ensimmäinen on yksinkertainen liiketoimintasääntö: package businessRules; tuontiyksiköitä. Jotain; public class BusinessRule { yksityinen BusinessRuleGateway gateway; julkinen BusinessRule (BusinessRuleGateway gateway) { this.gateway = yhdyskäytävä; } public void execute (String id) { gateway.startTransaction (); Jotain asia = gateway.getSomething (id); thing.makeChanges (); gateway.saveSomething (asia); gateway.endTransaction (); } }Liiketoiminnan säännöillä ei ole juurikaan painoarvoa. Tämä on vain yksi esimerkki. Tällaisia luokkia voisi olla enemmän, jotka toteuttavat monia erilaisia liiketoimintasääntöjä. Okei, mitä Gateway tarkalleen ottaen on? Se tarjoaa kaikki datan käyttötavat liiketoimintasääntöjen kautta. Toteuta se seuraavasti: package businessRules; tuontiyksiköitä. Jotain; julkinen rajapinta BusinessRuleGateway { Jotain getSomething (Merkkijonon tunniste); void startTransaction (); void saveSomething (Something thing); void endTransaction (); }Huomautus: Tämä on businessRulesissa. Okei, mikä on Jotain-luokka? Se edustaa yksinkertaista liiketoimintaobjektia. Laitoin sen entiteetteihin. pakettientiteetit; public class Jotain { public void makeChanges () { //... } }Lopulta BusinessRuleGateway-toteutuksessa tämä luokka tuntee todellisen tietokannan: pakettitietokanta; tuo businessRules.BusinessRuleGateway; tuontiyksiköitä. Jotain; public class MySqlBusinessRuleGateway toteuttaa BusinessRuleGateway { public Something getSomething (String id) { // käytä MySql:ää saadakseen asian. } public void startTransaction () { // start MySql-transaktio } public void saveSomething (Something thing) { // save thing in MySql } public void endTransaction () { // end MySql-tapahtuma } }Lisäksi on huomioitava, että liiketoimintasäännöt kutsuvat tietokantaa ajonaikaisesti; Kuitenkin käännösvaiheessa tietokanta sisältää ja riippuu businessRulesista. No, luulen että ymmärrän. Käytät vain polymorfismia peittääksesi sen, että tietokanta on toteutettu, liiketoimintasäännöiltä. Kuitenkin rajapinta tarvitaan edelleen, jotta kaikki tietokantatyökalut voidaan toteuttaa liiketoimintasääntöjen mukaisesti. Ei lainkaan. Emme ole yrittäneet tarjota tietokantatyökaluja liiketoimintasääntöjen mukaan. Sen sijaan he käyttävät liiketoimintasääntöjä luodakseen rajapintoja tarpeilleen. Näiden rajapintojen toteuttaminen mahdollistaa oikeiden työkalujen kutsumisen. Kyllä, mutta jos sinun täytyy käyttää kaikkia työkaluja kaikissa liiketoimintasäännöissä, laita työkalu vain gateway-rajapintaan. Ah, en usko, että ymmärrät vielä. Ymmärtää mitä? Tämä on jo selvää. Jokainen liiketoimintasääntö määrittelee vain yhden rajapinnan tarvitsemilleen datan käyttötyökaluille. Hetkinen, mitä sanot? Tämä on rajapinnan erotteluperiaate. Jokainen liiketoimintasääntöluokka käyttää vain tiettyjä tietokannan ominaisuuksia. Siksi kunkin liiketoimintasäännön tarjoamat rajapinnat voivat käyttää vain vastaavia palveluita. Tämä tarkoittaa kuitenkin, että on olemassa monia rajapintoja ja monia pieniä toteutusluokkia, jotka kutsuvat muita tietokantaluokkia. Hienoa, alat ymmärtää. Mutta se on liian sotkuista ja ajan hukkaa. Miksi tehdä näin? Tämä on järjestelmällistä ja säästää aikaa. Tule nyt, hanki paljon koodia pelkän koodin vuoksi. Päinvastoin, merkityksettömiä päätöksiä voidaan viivästyttää tärkeiden arkkitehtonisten päätösten vuoksi. Mitä tuo tarkoittaa? Muistan, että alussa sanoit haluavasi olla ohjelmistoarkkitehti, eikö niin? Haluat tehdä kaikki päätökset, joilla on oikeasti merkitystä. Kyllä, niin minäkin ajattelin. Haluat tehdä päätöksiä tietokannoista, web-palvelimista ja kehyksistä, eikö niin? Kyllä, sanot, ettei mikään siitä ole tärkeää. Pelkkää epäolennaista sisältöä. Niin juuri. Siinä se. Ohjelmistoarkkitehtien tekemät tärkeät päätökset ovat niitä, jotka mahdollistavat päätöksenteon tietokannoista, webpalvelimista ja kehyksistä. Mutta sinun täytyy ensin päättää, mitkä niistä! Ei, se ei toimi. Itse asiassa nämä voidaan päättää myöhemmin kehityssyklissä, kun tietoa on runsaasti. On katastrofi, jos arkkitehdit tunnistavat kehykset etukäteen vain huomatakseen, etteivät ne tarjoa vaadittua suorituskykyä tai asettavat sietämättömiä rajoitteita. Vasta kun arkkitehti päättää lykätä päätöstä, hän tekee päätöksen, kun tiedot ovat riittävät; Tiimit, jotka eivät käytä hitaita ja resursseja vaativia IO-laitteita ja kehyksiä, voivat luoda nopeita, kevyitä testiympäristöjä arkkitehtien harkinnan mukaan. Vain sen arkkitehdit välittävät siitä, mikä todella merkitsee, ja viivyttävät niitä, jotka eivät ole, ja tällainen tiimi on onnekas. Höpö höpö, en ymmärrä yhtään mitä tarkoitat. No, tutustu tähän artikkeliin tarkasti, muuten joudut odottamaan vielä 10 vuotta selvittääksesi sen.
| 
Julkaistu 27.9.2017 15.29.46
|
|
|
Julkaistu 28.9.2017 15.00.37
|
Vuokraisäntä|
Julkaistu 29.9.2017 8.34.23
|
Julkaistu 27.11.2018 11.12.17
|
