Kiire sissejuhatus puhtasse arhitektuuri

Avatud lähtekoodiga projektis, kuhu hakkasin panustama, toodi mulle mõiste “puhas arhitektuur”.

Esiteks oli see üsna valdav, kuid pärast mõningast lugemist oli see mõistlik. Mõtlesin, et teistele võib olla kasulik, kui panen oma mõtted kirja.

Sisukord

  • Visuaalsed esitused
  • Mõiste - esitatakse täppidega
  • Koodinäide
  • Ressursid

Visuaalsed esitused

Ma arvan, et alati on hea alustada mõningast visualiseerimisest.

Siin on selle kontseptsiooni kõige tavalisemad pildid.

Mõiste - esitatakse täppidega

Laiendatud allikast ja krediidist: Mattia Battiston, CC BY 4.0 all

Väärtus, mida see suudab pakkuda

  • Tõhus testimisstrateegia, mis järgib testimispüramiidi
  • Raamid on eraldatud üksikutesse moodulitesse. Kui (kui mitte) me meelt muudame, peame muutuse tegema ainult ühes kohas. Rakendusel on pigem kasutusjuhtumid kui seos CRUD-süsteemiga
  • Karjuv arhitektuur ehk karjub kavandatud kasutust. Kui vaatate paketi struktuuri, saate tehniliste üksikasjade nägemise asemel tunda, mida rakendus teeb
  • Kogu äriloogika on kasutusvaldkonnas, nii et seda on lihtne leida ja seda ei dubleerita kusagil mujal
  • Raske on valet teha, sest moodulid jõustavad kompileerimissõltuvusi. Kui proovite kasutada midagi, mis pole teile mõeldud, siis rakendus ei kompileeri
  • See on alati valmis kasutusele võtma, jättes objekti juhtmestiku viimaseks. Või kasutades funktsioonilippe, nii saame kõik pideva integratsiooni eelised
  • Mitu lugu töötab nii, et erinevad paarid saaksid sama loo kallal korraga töötada, et see kiiremini lõpule viia
  • Hea monoliit koos selgete kasutusjuhtumitega, mida saate hiljem mikroteenustesse jagada, kui olete nende kohta rohkem teada saanud

Üksused

  • Esitage oma domeeni objekti
  • Rakendage ainult loogikat, mis on üldiselt kohaldatav kogu üksusele (nt hosti nime vormingu kinnitamine)
  • Tavalised objektid: pole raame, pole märkusi

Kasuta juhtumeid

  • Esitage oma äritegevust: seda saate rakendusega teha. Oodake iga äritoimingu jaoks ühte kasutusjuhtu
  • Puhas äriloogika, tavaline kood (välja arvatud ehk mõned utili teegid)
  • Kasutusjuhtum ei tea, kes selle käivitas ja kuidas tulemusi hakatakse esitama (näiteks võib see olla veebilehel või - tagastada JSON-na või lihtsalt logida jne).
  • Viskab ärilisi erandeid

Liidesed / adapterid

  • Andmete hankimine ja salvestamine mitmest allikast ja paljudest allikatest (andmebaas, võrguseadmed, failisüsteem, kolmandad isikud ja nii edasi).
  • Määrake liidesed andmetele, mida nad vajavad mõne loogika rakendamiseks. Üks või mitu andmepakkujat rakendavad liidese, kuid kasutusjuht ei tea, kust andmed pärinevad
  • Rakendage kasutusjuhtumiga määratletud liidesed
  • Rakendusega suhtlemiseks on võimalusi, mis hõlmavad tavaliselt edastamismehhanismi (näiteks REST API-d, plaanitud tööd, GUI, muud süsteemid)
  • Käivitage kasutusjuht ja teisendage tulemus edastamismehhanismi jaoks sobivasse vormingusse
  • MVC kontroller

Välised liidesed

  • Kasutage mis tahes raamistikku, mis on kõige sobivam (siin hakatakse neid nagunii isoleerima)

Koodinäide

Vaadake GitHubi struktuuri.

Kõigepealt on oluline mõista, et puhas arhitektuur on korraldusprintsiipide kimp. Seega on kõik isiklikeks kohandusteks avatud seni, kuni põhiideed jäävad puutumatuks. Lingitud hoidla on algse projekti hargnemiskoht, mis selle arhitektuurikujunduse idee mulle tõi. Tutvuge julgelt ka algse projektiga, kuna see peegeldab edasisi täiustusi.

Webmineri kaust on struktureeritud põhikihtideks:

  1. üksused
  2. use_cases
  3. liidesed_adapterid
  4. välised_liidesed

See peab kajastama kujundusmustri põhilist lähenemist.

  • Alustades entitiesnäete, et selle projekti põhimudel onarxiv_document
  • Järgmine kaust use_casesnäitab meie kasutusjuhtu, nimelt arxiv lehe taotlemist
  • Pärast seda käime läbi interface_adapterskausta, mis pakub adaptereid REST-rakenduses protsessitaotluste jaoks või seriaalimiseks
  • Viimane ja viimane kiht on external_interfaces. Siin kasutame REST-funktsiooni rakendamiseks kolviserverit

Kõik need kihid sõltuvad südamiku kihtidest, kuid mitte vastupidi.

Üks oluline märkus: seda pole 100% õigesti repositooriumis rakendatud.

Miks? Sest kasutusjuhtumid on tegelikult erinevad. Tegelikkuses on peamine kasutusviis struktureeritud andmete esitamine. Teine kasutusjuht on andmete hankimine lehelt arxiv.

Kas märkasite seda viga arhitektuuris? Kui jah, siis palju õnne! Lisaks sellele, et tõite sellesse artiklisse piisavalt uudishimu, mõistate tõenäoliselt põhimõtteid piisavalt hästi, et luua oma juhtum ja neid mõisteid tegelikkuses rakendada!

Kas sa nõustud? Kui ei, siis miks? Täname, et lugesite minu artiklit! Jätke julgelt tagasisidet!

Ressursid

Siin on mõned artiklid, millest leidsin abi puhta arhitektuuri mõiste mõistmisel:

  • //8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
  • //www.codingblocks.net/podcast/clean-architecture-make-your-architecture-scream/
  • //github.com/mattia-battiston/clean-architecture-example
  • //medium.com/@tiagoflores_23976/how-choose-the-appropriate-ios-architecture-mvc-mvp-mvvm-viper-or-clean-architecture-2d1e9b87d48
  • //de.slideshare.net/HimanshuDudhat1/mvp-clean-architecture
  • //softwareengineering.stackexchange.com/questions/336677/what-is-the-difference-between-mvp-and-clean-architecture
  • //engineering.21buttons.com/clean-architecture-in-django-d326a4ab86a9
  • //gist.github.com/ygrenzinger/14812a56b9221c9feca0b3621518635b
  • //medium.freecodecamp.org/how-to-write-robust-apps-consistently-with-the-clean-architecture-9bdca93e17b
  • //marconijr.com/posts/clean-architecture-practice/

Daniel on LL.M. äriõiguse tudeng, töötades Viinis tarkvarainseneri ja tehnikaga seotud ürituste korraldajana. Tema praegused isiklikud õppimispüüdlused keskenduvad masinõppele.

Ühendage:

  • LinkedIn
  • Github
  • Keskmine
  • Twitter
  • Steemit
  • Hashnode