Ką galite pasakyti apie švarią architektūrą?

Švari architektūra (Clean Architecture), populiarinta Roberto Martin ("Dėdė Bob"), yra principų rinkinys, skirtas kodo organizavimui, siekiant sukurti lankstų, testuojamą ir lengvai prižiūrimą sistemą.

Pagrindinės idėjos:

1. Sluoksnių atskyrimas: Kodas suskirstytas į koncentriškus ratus, kur vidiniai ratai apima verslo logiką, o išoriniai – įgyvendinimo detales (UI, duomenų bazės, išoriniai API).
2. Priklausomybė nuo vidinių sluoksnių: Išoriniai sluoksniai priklauso nuo vidinių, bet ne atvirkščiai. Tai pasiekiama naudojant priklausomybių inversijos principą.
3. Inkapuliacija: Kiekvienas sluoksnis slepia savo įgyvendinimo detales nuo išorinių sluoksnių.
4. Testuojamumas: Verslo logika, esanti centrinėse sluoksniuose, nepriklauso nuo išorinių detalių, todėl ją lengva testuoti izoliuotai.
5. Nepriklausomybė nuo karkasų: Pagrindinės verslo taisyklės nėra susietos su konkrečiais karkasais, UI ar duomenų bazėmis.

Sluoksniai (pavyzdys):

• Entities: Apima verslo objektus ir taisykles (pavyzdžiui, User klasė su verslo logika, susijusia su naudotoju).
• Use Cases (Interactors): Apima specifinę programos verslo logiką (pavyzdžiui, GetUserUseCase). Jie koordinuoja sąveiką tarp Entities ir Gateway Interfaces.
• Interface Adapters: Pritaiko duomenis iš išorinių šaltinių į formatą, suprantamą Use Cases ir Entities (pavyzdžiui, Presenteriai UI, Gateway įgyvendinimai duomenų bazėms).
• Frameworks & Drivers: Išorinis sluoksnis, kuriame yra karkasai (UI, duomenų bazės, žiniatinklio paslaugos).

Priklausomybių inversijos principas vaidina pagrindinį vaidmenį. Vidiniai sluoksniai apibrėžia sąsajas (Gateway Interfaces), o išoriniai sluoksniai įgyvendina šias sąsajas. Tai parodyta šioje schemoje:

+-----------------+      +-------------------+      +--------------------+      +------------------------+
| Frameworks &    |----->|   Interface       |<-----|    Use Cases       |<-----|        Entities          |
| Drivers (UI, DB)|      |   Adapters        |      |  (Interactors)     |      |      (Business Rules)    |
+-----------------+      |  (Presenters,     |      |                    |      +------------------------+
                         |  Gateway Impls)   |      |                    |
                         +-------------------+      +--------------------+

Rodyklės rodo priklausomybių kryptį. Visos priklausomybės nukreiptos į vidų, link Entities sluoksnio.

Android kūrime Clean Architecture dažnai įgyvendinama naudojant tokius komponentus:

• UI sluoksnis (Presentation): Activity, Fragment, ViewModel, UI logika. Priklauso nuo Domain sluoksnio.
• Domain sluoksnis (Use Cases): Programos verslo logika. Nėra priklausomas nuo kitų sluoksnių.
• Data sluoksnis: Duomenų šaltiniai (tinklas, duomenų bazės), repository. Įgyvendina Domain sluoksnyje apibrėžtas sąsajas.

Pavyzdinė struktūra:

root
├── app
│   ├── src
│   │   └── main
│   │       └── java
│   │           └── com
│   │               └── example
│   │                   └── myapp
│   │                       ├── presentation  // UI sluoksnis (ViewModel, Activity, Fragment)
│   │                       │   ├── ui
│   │                       │   └── viewmodel
│   │                       ├── domain      // Domain sluoksnis (Use Cases, Entities, Interfaces)
│   │                       │   ├── entity
│   │                       │   ├── repository  // Domain sąsajos
│   │                       │   └── usecase
│   │                       └── data        // Data sluoksnis (Repository, Data Sources, Mappers)
│   │                           ├── local       // Local Data Source (Room)
│   │                           ├── remote      // Remote Data Source (Retrofit)
│   │                           ├── mapper
│   │                           └── repository  // Data įgyvendinimai, plėtojantys Domain sąsajas
│   └── build.gradle
└── build.gradle

Privalumai:

• Testuojamumas: Verslo logika izoliuota ir lengvai testuojama.
• Lankstumas: Lengva keisti išorinius priklausomus komponentus (pavyzdžiui, pereiti nuo Room prie Realm).
• Palaikymas: Aiškus atsakomybės pasidalijimas palengvina kodo supratimą ir priežiūrą.
• Nepriklausomybė nuo technologijų: Verslo logika nėra susieta su specifiniais Android karkasais ar bibliotekomis.

Trūkumai:

• Sudėtingumas: Gali būti pradžioje sudėtingesnė suprasti ir įgyvendinti, ypač mažesniuose projektuose.
• Daugiau kodo: Reikalauja rašyti daugiau klasių ir sąsajų, palyginti su paprastesnėmis architektūromis.

Apskritai, Clean Architecture yra galingas požiūris, skirtas kurti skalę ir palaikomus Android programėles, ypač vidutinio ir didelio sudėtingumo projektuose. Ji skatina kurti aplink verslo logiką, o ne technines detales.