Universul este construit pe baza unui plan a cărui simetrie profundă este prezentă în structura interioară a intelectului uman. - Paul Valery
Arhitectura Clean este extraordinară! Arhitectura Clean este frumoasă! Arhitectura Clean este simetrică! Arhitectura Clean este naturală! Arhitectura Clean ar trebui pur și simplu să fie firească!
Arhitectura Clean este structura care rezultă într-un mod natural în momentul în care se aplică DIP: "High level modules should not depend on low level modules. Both should depend on abstractions"
Modulele "high level" reprezintă partea cea mai importantă din implementarea unei aplicații; reflectă politicile din implementarea aplicației, abstracțiile generale care guvernează întreaga aplicație; reprezintă conceptele care nu variază când detaliile se schimbă.
Prin opoziție, modulele "low level" se referă la partea de detalii. Acestea sunt mecanismele tehnice generice care susțin modulele "high level": logging, OOM, ORM, e-mail, sms…
Patternul traditional Layers încalcă DIP și, din cauza aceasta, implică niște consecințe destul de nefericite.
De zeci de ani folosim Layers pentru a structura diverse aplicații. La fel, de zeci de ani, Layers a fost sinonim cu o structura de calitate - sau aveai Layers, sau aveai BBOM (Big Ball of Mud anti-pattern).
De zeci de ani pretindem că folosim și aplicăm SOLID, dar de fapt nu o facem. În cel mai bun caz, putem afirma că am aplicat SOLI.
Cel puțin în lumea .NET, Layers încalcă DIP prin impunerea unei referințe de la assembly-urile high level către cele low level care fac parte din layer-ul de Infrastructură:
În linii mari, Clean Architecture respecta DIP, pe când Layers nu face acest lucru.
Clean concentrează cea mai importantă parte a implementării în partea centrală, externalizând toate detaliile.
Principiul care face ca acest model să funcționeze este numit regula dependenței: "Dependentele în cod pot să fie orientate doar spre interior". Aceasta este de fapt o definiție mult mai pragmatică a DIP.
Dacă vă imaginați un model asimetric ce derivă din structura Layers clasică, dar
care se conformează DIP, acesta ar arăta cam așa:
Săgețile reprezintă dependințe în cod.
Faptul că reprezentarea Clean Architecture este simetrică, folosind cercuri concentrice, nu este o coincidență. Poate nu este foarte evident, dar această reprezentare ascunde un principiu foarte puternic: toate detaliile sunt doar detalii!
Clean Architecture se concentrează pe cea mai importantă parte a implementării unei aplicații. Acesta este centrul aplicației și acesta este aspectul la care s-a referit DIP sub numele de "high level modules" timp de peste 10 ani. Din punctul de vedere al centrului aplicației, framework-ul de livrare nu este cu nimic mai special decât baza de date sau framework-ul de logare.
Acesta este motivul pentru care Clean Architecture îndreaptă procesul de dezvoltare spre o abordare de tip "domain-out" și pentru care reprezintă un mediu mult mai confortabil și mai natural pentru Domain Driven Design. Acesta este și motivul pentru care întârzierea deciziilor legate de tehnologii vine în mod mult mai natural când folosim Clean Architecture. Este chiar modelul mental impus de cercurile concentrice care te ajută să vezi pădurea, în ciuda copacilor.
După părerea mea, Cone Architecture este doar o metaforă mai expresivă pentru acest tip de structura software. Da, eu am inventat termenul ăsta.
Este vorba despre două perspective diferite: dacă te uiți de sus, vei vedea niște cercuri concentrice guvernate de regula dependenței, care afirmă că dependențele în cod pot fi orientate doar spre interior. Acesta este un punct de vedere strict tehnic.
Dar dacă privești structura dintr-o parte, poți să vezi foarte clar ce vrea să
spună DIP prin module "high level" și module "low level". Poți acum să faci
deduci mult mai ușor ierarhia straturilor după nivelul lor de abstracție.
Cercurile interioare sunt de nivel mai înalt decât cele exterioare.
de Radu Butnaru
de Ovidiu Deac
