Mida te võite öelda puhta arhitektuuri kohta?

Puhas arhitektuur (Clean Architecture), mida populariseeris Robert Martin („Onu Bobi”), on põhimõtete kogum, mis on suunatud koodi korraldamisele, et luua paindlik, testitav ja hõlpsasti hooldatav süsteem.

Peamised ideed:

1. Kihistamine: Kood jaguneb kontsentrilisteks ringideks, kus sisemised ringid sisaldavad äriloogikat ning välised – teostuse üksikasju (UI, andmebaasid, välised API-d).
2. Sõltuvus sisemistest kihtidest: Välised kihid sõltuvad sisemistest, kuid mitte vastupidi. Seda saavutatakse sõltuvuste inversiooni põhimõtte abil.
3. Kapseldus: Iga kiht varjab oma teostuse üksikasju väliste kihtide eest.
4. Testitavus: Kesksetes kihtides olev äriloogika ei sõltu välisestest detailidest, muutes selle hõlpsasti isoleeritult testitavaks.
5. Sõltumatus raamistikest: Äri põhireeglid ei ole seotud konkreetsete raamistikudega, UI või andmebaasidega.

Kihid (näide):

• Entities: Sisaldavad ärikontseptsioone ja reegleid (näiteks klass User koos kasutajaga seotud äriloogikaga).
• Use Cases (Interactors): Sisaldavad spetsiifilist rakenduse äriloogikat (näiteks GetUserUseCase). Nad koordineerivad suhtlust Entities ja Gateway Interface'ide vahel.
• Interface Adapters: Kohandavad väliste allikate andmeid sellesse formaati, mida mõistavad Use Cases ja Entities (näiteks UI presenterid, Gateway implementatsioonid andmebaaside jaoks).
• Frameworks & Drivers: Väliskiht, mis sisaldab raamistikku (UI, andmebaasid, veebiteenused).

Sõltuvuste inversiooni põhimõte mängib võtmerolli. Sisemised kihid määratlevad liidesed (Gateway Interfaces), ning välised kihid teostavad need liidesed. Seda näitab järgmine skeem:

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

Noored näitavad sõltuvuste suunda. Kõik sõltuvused on suunatud sissepoole, Entities kihti.

Androidi arenduses rakendatakse Clean Architecture sageli selliste komponentide abil:

• UI kiht (Presentation): Activity, Fragment, ViewModel, UI loogika. Sõltub Domain kihist.
• Domain kiht (Use Cases): Rakenduse äriloogika. Ei sõltu teistest kihtidest.
• Andmekiht: Andmeallikad (võrk, andmebaasid), repository. Teostab Domain kihis määratletud liideseid.

Näide struktuurist:

root
├── app
│   ├── src
│   │   └── main
│   │       └── java
│   │           └── com
│   │               └── example
│   │                   └── myapp
│   │                       ├── presentation  // UI kiht (ViewModel, Activity, Fragments)
│   │                       │   ├── ui
│   │                       │   └── viewmodel
│   │                       ├── domain      // Domain kiht (Use Cases, Entities, Interfaces)
│   │                       │   ├── entity
│   │                       │   ├── repository  // Domain liidesed
│   │                       │   └── usecase
│   │                       └── data        // Data kiht (Repositories, Data Sources, Mappers)
│   │                           ├── local       // Kohalik andmeallikas (Room)
│   │                           ├── remote      // Kauglike andmeallikas (Retrofit)
│   │                           ├── mapper
│   │                           └── repository  // Andmete implementatsioonid, mis laiendavad Domain liideseid
│   └── build.gradle
└── build.gradle

Eelised:

• Testitavus: Äriloogika on isoleeritud ja kergesti testitav.
• Paindlikkus: Lihtne asendada väliseid sõltuvusi (näiteks, vahetada Room Realm-iga).
• Hooldatavus: Selge vastutusalade jaotus muudab koodi lihtsamini mõistetavaks ja hooldatavaks.
• Sõltumatus tehnoloogiatest: Äriloogika ei ole seotud spetsiifiliste Androidi raamistikudega või teekidega.

Miinused:

• Suurenenud keerukus: Alguses võib olla keerulisem mõista ja rakendada, eriti väiksemates projektides.
• Rohkem koodi: Nõuab rohkem klasside ja liideste kirjutamist võrreldes lihtsamate arhitektuuridega.

Üldiselt on Clean Architecture võimas lähenemisviis skaleeritavate ja hooldatavate Android rakenduste loomiseks, eriti keskmise ja suure keerukusega projektide puhul. See soodustab arendust äriloogika ümber, mitte tehniliste detailide.