Sobes.tech
Middle+

Ko jūs varat pastāstīt par tīru arhitektūru?

sobes.tech AI

Atbilde no AI

Tīra arhitektūra (Clean Architecture), ko popularizējis Roberts Martins («Onkulis Bobs»), ir principu kopums, kas paredzēts koda organizēšanai, lai izveidotu elastīgu, testējamu un viegli uzturamu sistēmu.

Galvenās idejas:

  1. Slāņu sadalījums: Kods ir sadalīts koncentriska gredzenu formā, kur iekšējie gredzeni satur biznesa loģiku, bet ārējie – īstenošanas detaļas (UI, datu bāzes, ārējie API).
  2. Atkarība no iekšējiem slāņiem: Ārējie slāņi ir atkarīgi no iekšējiem, bet ne otrādi. To panāk ar atkarību inversijas principu.
  3. Inkapulācija: Katrs slānis slēpj savas īstenošanas detaļas no ārējiem slāņiem.
  4. Testējamība: Biznesa loģika, kas atrodas centrālajos slāņos, nav atkarīga no ārējām detaļām, padarot to viegli testējamu izolācijā.
  5. Neatkarība no karkasiem: Galvenās biznesa noteikumi nav saistīti ar konkrētiem karkasiem, UI vai datu bāzēm.

Slāņi (piemērs):

  • Entities: Satur biznesa objektus un noteikumus (piemēram, User klase ar biznesa loģiku, kas saistīta ar lietotāju).
  • Use Cases (Interactors): Satur specifisku lietojumprogrammas biznesa loģiku (piemēram, GetUserUseCase). Tie koordinē sadarbību starp Entities un Gateway Interfaces.
  • Interface Adapters: Pielāgo datus no ārējiem avotiem formātā, kas saprotams Use Cases un Entities (piemēram, Presenterus UI, Gateway īstenojumus datu bāzēm).
  • Frameworks & Drivers: Ārējais slānis, kas satur karkasus (UI, datu bāzes, tīmekļa pakalpojumus).

Atkarību inversijas princips spēlē galveno lomu. Iekšējie slāņi definē saskarnes (Gateway Interfaces), bet ārējie slāņi īsteno šīs saskarnes. To ilustrē šajā shēmā:

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

Lentes norāda uz atkarību virzienu. Visas atkarības ir vērstas iekšā, uz Entities slāni.

Android izstrādē Clean Architecture bieži tiek īstenota ar šādiem komponentiem:

  • UI slānis (Presentation): Activity, Fragment, ViewModel, UI loģika. Atkarīgs no Domain slāņa.
  • Domain slānis (Use Cases): Programmas biznesa loģika. Nav atkarīgs no citiem slāņiem.
  • Data slānis: Datu avoti (tīkls, datu bāzes), repository. Īsteno Domain slānī definētās saskarnes.

Piemērs struktūrai:

root
├── app
│   ├── src
│   │   └── main
│   │       └── java
│   │           └── com
│   │               └── example
│   │                   └── myapp
│   │                       ├── presentation  // UI slānis (ViewModel, Activity, Fragments)
│   │                       │   ├── ui
│   │                       │   └── viewmodel
│   │                       ├── domain      // Domain slānis (Use Cases, Entities, Interfaces)
│   │                       │   ├── entity
│   │                       │   ├── repository  // Domain saskarnes
│   │                       │   └── usecase
│   │                       └── data        // Data slānis (Repository, Data Sources, Mappers)
│   │                           ├── local       // Local Data Source (Room)
│   │                           ├── remote      // Remote Data Source (Retrofit)
│   │                           ├── mapper
│   │                           └── repository  // Data īstenojumi, kas paplašina Domain saskarnes
│   └── build.gradle
└── build.gradle

Priekšrocības:

  • Testējamība: Biznesa loģika ir izolēta un viegli testējama.
  • Elastība: Viegli nomainīt ārējās atkarības (piemēram, pāriet no Room uz Realm).
  • Uzturējamība: Skaidrs atbildības sadalījums padara kodu vieglāk saprotamu un uzturamu.
  • Neatkarība no tehnoloģijām: Biznesa loģika nav saistīta ar specifiskiem Android karkasiem vai bibliotēkām.

Trūkumi:

  • Sarežģītība: Sākotnēji var būt grūtāk saprast un īstenot, īpaši mazāku projektu gadījumā.
  • Vairāk koda: Prasa rakstīt vairāk klases un saskarnes, salīdzinot ar vienkāršākām arhitektūrām.

Kopumā, Clean Architecture ir jaudīgs pieeja, kas paredzēta mērogojamu un uzturamu Android lietojumprogrammu izstrādei, īpaši vidēja un liela sarežģītības projektiem. Tā veicina izstrādi ap biznesa loģiku, nevis tehniskajām detaļām.