de Daniel Deutsch

O introducere rapidă la arhitectura curată

O introducere rapida la arhitectura curata
Fotografie de Rubén García pe Unsplash – https://unsplash.com/photos/R-wQExeiGrc

Într-un proiect open source Am început să contribui, conceptul „arhitectură curată” mi-a fost adus.

În primul rând, a fost destul de copleșitor, dar după o lectură a avut sens. M-am gândit că ar putea fi util pentru alții dacă îmi notez gândurile.

Cuprins

Reprezentări vizuale

Cred că este întotdeauna bine să începi cu o anumită vizualizare.

Iată cele mai frecvente imagini ale acestui concept.

ad-banner
1611566826 428 O introducere rapida la arhitectura curata
1611566826 219 O introducere rapida la arhitectura curata
Sursă și credit: https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html .https://www.codingblocks.net/podcast/clean-architecture-make-your-architecture-scream/
O introducere rapida la arhitectura curata
1611566827 17 O introducere rapida la arhitectura curata
Sursă și credit: Mattia Battiston, sub CC BY 4.0, https://github.com/mattia-battiston/clean-architecture-example
1611566827 809 O introducere rapida la arhitectura curata
Sursă și credit: https://marconijr.com/posts/clean-architecture-practice/

Conceptul – prezentat în puncte glonț

Extins de la sursă și credit: Mattia Battiston, sub CC BY 4.0

Valoarea pe care o poate oferi

  • O strategie eficientă de testare care urmează piramidei de testare
  • Cadrele sunt izolate în module individuale. Când (nu dacă) ne răzgândim, trebuie doar să facem o schimbare într-un singur loc. Aplicația are cazuri de utilizare, mai degrabă decât legată de un sistem CRUD
  • Arhitectura țipătoare, de asemenea, țipă utilizarea intenționată. Când vă uitați la structura pachetului, veți avea o idee despre ceea ce face aplicația, mai degrabă decât să vedeți detalii tehnice
  • Toată logica de afaceri se află într-un caz de utilizare, deci este ușor de găsit și nu este duplicat în altă parte
  • Greu de făcut un lucru greșit, deoarece modulele aplică dependențe de compilare. Dacă încercați să utilizați ceva pentru care nu sunteți destinat, aplicația nu compilează
  • Este întotdeauna gata de desfășurare lăsând cablajul obiectului pentru final. Sau folosind semnalizatoare de caracteristici, astfel încât să obținem toate avantajele integrării continue
  • Lucrări multiple pe povești, astfel încât perechi diferite să poată lucra cu ușurință pe aceeași poveste în același timp, pentru ao finaliza mai repede
  • Monolit bun, cu cazuri de utilizare clare pe care le puteți împărți mai târziu în microservicii, după ce ați aflat mai multe despre ele

Entități

  • Reprezentați-vă obiectul de domeniu
  • Aplicați numai logica care se aplică în general întregii entități (de exemplu, validarea formatului unui nume de gazdă)
  • Obiecte simple: fără cadre, fără adnotări

Cazuri de utilizare

  • Reprezentați-vă acțiunile comerciale: este ceea ce puteți face cu aplicația. Așteptați un caz de utilizare pentru fiecare acțiune comercială
  • Logică pură a afacerii, cod simplu (cu excepția poate a unor biblioteci utile)
  • Cazul de utilizare nu știe cine a declanșat-o și cum vor fi prezentate rezultatele (de exemplu, ar putea fi pe o pagină web sau – returnate ca JSON, sau pur și simplu înregistrate și așa mai departe.)
  • Aruncă excepții de afaceri

Interfețe / adaptoare

  • Preluarea și stocarea datelor de la și către o serie de surse (bază de date, dispozitive de rețea, sistem de fișiere, terțe părți etc.)
  • Definiți interfețele pentru datele de care au nevoie pentru a aplica o anumită logică. Unul sau mai mulți furnizori de date vor implementa interfața, dar cazul de utilizare nu știe de unde provin datele
  • Implementați interfețele definite de cazul de utilizare
  • Există modalități de a interacționa cu aplicația și implică de obicei un mecanism de livrare (de exemplu, API-uri REST, joburi programate, GUI, alte sisteme)
  • Declanșați un caz de utilizare și convertiți rezultatul în formatul adecvat pentru mecanismul de livrare
  • controlerul pentru un MVC

Interfețe externe

  • Utilizați orice cadru este cel mai potrivit (oricum vor fi izolate aici)

Exemplu de cod

Vedeți structura de pe GitHub.

În primul rând, este important să înțelegem că arhitectura curată este un pachet de principii de organizare. Prin urmare, totul este deschis ajustărilor personale atâta timp cât ideile de bază sunt păstrate intacte. Depozitul conectat este o bifurcație a proiectului original care mi-a adus această idee de design arhitectural. Simțiți-vă liber să verificați și proiectul original, deoarece reflectă îmbunătățiri suplimentare.

Folderul webminer este structurat în straturile de bază:

  1. entități
  2. use_cases
  3. interfețe_adaptoare
  4. interfețe_ externe
1611566827 816 O introducere rapida la arhitectura curata
Structura folderului webminer

Acesta trebuie să reflecte abordarea de bază a modelului de proiectare.

  • Începând de la entities, puteți vedea că modelul de bază al acestui proiect este arxiv_document
  • Următorul folder, use_cases arată cazul nostru de utilizare și anume pentru a solicita pagina arxiv
  • După aceea, trecem prin interface_adapters folder care furnizează adaptoare pentru solicitări de proces într-o aplicație REST sau pentru serializare
  • Ultimul și ultimul strat este external_interfaces. Aici folosim serverul flask pentru a implementa funcționalitatea REST

Toate aceste straturi sunt dependente de straturile de bază, dar nu invers.

O notă importantă: Aceasta nu este 100% corect implementată în depozit.

De ce? Deoarece cazurile de utilizare sunt de fapt diferite. În realitate, principalul caz de utilizare este furnizarea de date structurate. Un alt caz de utilizare este obținerea datelor din pagina arxiv.

Ați identificat această eroare în arhitectură? Dacă da, felicitări! Nu numai că ați adus suficientă curiozitate acestui articol, dar probabil că înțelegeți principiile suficient de bine pentru a vă construi propriul caz și a aplica conceptele în realitate!

Ești de acord? Dacă nu, de ce? Mulțumesc că mi-ai citit articolul! Simțiți-vă liber să lăsați orice feedback!

Resurse

Iată câteva articole care mi s-au părut utile în înțelegerea conceptului de „arhitectură curată”:

Daniel este LL.M. student la dreptul afacerilor, lucrează ca inginer software și organizator de evenimente legate de tehnologie la Viena. Eforturile sale actuale de învățare personală se concentrează pe învățarea automată.

Conectați-vă la: