Nopea esittely puhtaasta arkkitehtuurista

Avoimen lähdekoodin projektissa, johon aloin osallistua, tuotiin minulle puhtaan arkkitehtuurin käsite.

Ensinnäkin se oli melko ylivoimainen, mutta jonkin verran lukemisen jälkeen se oli järkevää. Luulin, että voi olla hyödyllistä muille, jos kirjoitan muistini.

Sisällysluettelo

  • Visuaaliset esitykset
  • Käsite - esitetty luettelomerkkeinä
  • Koodiesimerkki
  • Resurssit

Visuaaliset esitykset

Mielestäni on aina hyvä aloittaa visualisoinnilla.

Tässä on yleisimmät kuvat tästä konseptista.

Käsite - esitetty luettelomerkkeinä

Laajennettu lähteestä ja luotosta: Mattia Battiston, CC BY 4.0

Arvo, jonka se voi tarjota

  • Tehokas testausstrategia, joka seuraa testauspyramidia
  • Kehykset on eristetty yksittäisiksi moduuleiksi. Kun (ei jos) muutamme mielemme, meidän on tehtävä muutos vain yhdessä paikassa. Sovelluksella on käyttötapauksia sen sijaan, että se olisi sidottu CRUD-järjestelmään
  • Huutava arkkitehtuuri eli se huutaa sen käyttötarkoituksen. Kun tarkastelet pakettirakennetta, saat tuntuman sovelluksen toiminnalle sen sijaan, että näet tekniset yksityiskohdat
  • Kaikki liiketoimintalogiikat ovat käyttötapauksissa, joten ne on helppo löytää eikä kopioida missään muualla
  • Vaikea tehdä väärä asia, koska moduulit pakottavat kokoamisriippuvuudet. Jos yrität käyttää jotain, jota et ole tarkoitettu, sovellus ei käännä
  • Se on aina valmis käyttöön ottamalla kohteen johdotus viimeiseksi. Tai käyttämällä ominaisuuslippuja, niin saamme kaikki jatkuvan integraation edut
  • Useat teokset tarinoista, jotta eri parit voivat helposti työskennellä saman tarinan kanssa samanaikaisesti, jotta se saadaan nopeammin valmiiksi
  • Hyvä monoliitti ja selkeät käyttötapaukset, jotka voit jakaa mikropalveluihin myöhemmin, kun olet oppinut niistä lisää

Entiteetit

  • Edusta verkkotunnuksesi objektia
  • Käytä vain logiikkaa, joka on yleisesti sovellettavissa koko entiteettiin (esim. Isäntänimen muodon vahvistaminen)
  • Tavalliset objektit: ei kehyksiä, ei merkintöjä

Käytä koteloita

  • Esittele liiketoimintasi: se on mitä voit tehdä sovelluksella. Odota yksi käyttötapaus jokaiselle liiketoiminnalle
  • Puhdas liiketoimintalogiikka, tavallinen koodi (paitsi ehkä jotkut utils-kirjastot)
  • Käyttötapaus ei tiedä kuka laukaisi sen ja miten tulokset esitetään (esimerkiksi voi olla verkkosivulla tai - palautettu JSON-muodossa tai yksinkertaisesti kirjautuneena jne.)
  • Heittää liiketoiminnan poikkeuksia

Liitännät / sovittimet

  • Nouda ja tallenna tietoja useista lähteistä (tietokanta, verkkolaitteet, tiedostojärjestelmä, kolmannet osapuolet ja niin edelleen).
  • Määritä rajapinnat tiedoille, joita he tarvitsevat jonkin logiikan soveltamiseksi. Yksi tai useampi tiedon tarjoaja ottaa käyttöön käyttöliittymän, mutta käyttötapaus ei tiedä mistä tiedot tulevat
  • Toteuta käyttötapauksen määrittelemät rajapinnat
  • On tapoja olla vuorovaikutuksessa sovelluksen kanssa, ja niihin liittyy tyypillisesti jakelumekanismi (esimerkiksi REST-sovellusliittymät, ajoitetut työt, käyttöliittymä, muut järjestelmät)
  • Käynnistä käyttötapaus ja muunna tulos sopivaan muotoon jakelumekanismille
  • MVC: n ohjain

Ulkoiset liitännät

  • Käytä mitä tahansa sopivinta kehystä (ne eristetään täällä joka tapauksessa)

Koodiesimerkki

Katso rakenne GitHubissa.

Ensinnäkin on tärkeää ymmärtää, että puhdas arkkitehtuuri on nippu organisointiperiaatteita. Joten siksi kaikki on henkilökohtaista mukautusta varten niin kauan kuin ydinajat pysyvät ennallaan. Linkitetty arkisto on haarukka alkuperäisestä projektista, joka toi tämän arkkitehtuurisuunnittelun minulle. Voit vapaasti tarkistaa myös alkuperäisen projektin, koska se heijastaa lisäparannuksia.

Webminer-kansio on jäsennelty peruskerroksiin:

  1. yhteisöt
  2. Käytä koteloita
  3. interfaces_adapters
  4. ulkoiset_liitännät

Sen on heijastettava suunnittelumallin perustavanlaatuista lähestymistapaa.

  • Alkaen entitiesvoit nähdä, että tämän projektin ydinmalli onarxiv_document
  • Seuraava kansio use_casesnäyttää käyttötapamme, nimittäin arxiv-sivun pyytämisen
  • Sen jälkeen käymme läpi interface_adapterskansion, joka tarjoaa sovittimia REST-sovelluksen prosessipyyntöihin tai sarjallisuuteen
  • Viimeinen ja viimeinen kerros on external_interfaces. Tässä käytämme pullopalvelinta REST-toiminnon toteuttamiseen

Kaikki nämä kerrokset ovat riippuvaisia ​​ydinkerroksista, mutta eivät päinvastoin.

Yksi tärkeä huomautus: Tätä ei ole toteutettu 100-prosenttisesti oikein arkistossa.

Miksi? Koska käyttötapaukset ovat itse asiassa erilaisia. Todellisuudessa pääasiallinen käyttötapaus on strukturoidun tiedon toimittaminen. Toinen käyttötapaus on tietojen hankkiminen arxiv-sivulta.

Löysitkö tämän virheen arkkitehtuurissa? Jos kyllä, onnittelut! Et vain tuonut tarpeeksi uteliaisuutta tähän artikkeliin, mutta ymmärrät todennäköisesti periaatteet riittävän hyvin rakentaaksesi oman tapauksesi ja soveltamalla käsitteitä todellisuudessa!

Oletko samaa mieltä? Jos ei, miksi? Kiitos kun lukit artikkelini! Voit vapaasti jättää palautetta!

Resurssit

Tässä on joitain artikkeleita, joista pidin hyödyllisiä puhtaan arkkitehtuurin käsitteen ymmärtämisessä:

  • //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 oikeustieteen kandidaatti. kauppatieteiden opiskelija, työskentelee ohjelmistoinsinöörinä ja teknisten tapahtumien järjestäjänä Wienissä. Hänen nykyiset henkilökohtaiset oppimispyrkimyksensä keskittyvät koneoppimiseen.

Yhdistä:

  • LinkedIn
  • Github
  • Keskitaso
  • Viserrys
  • Steemit
  • Hashnode