Co můžete říct o čisté architektuře?

Čistá architektura (Clean Architecture), kterou popularizoval Robert Martin ("Uncle Bob"), představuje soubor principů pro organizaci kódu, zaměřených na tvorbu flexibilního, testovatelného a snadno udržovatelného systému.

Hlavní myšlenky:

1. Rozdělení do vrstev: Kód je rozdělen do soustředných kruhů, kde vnitřní vrstvy obsahují obchodní logiku a vnější detaily implementace (UI, databáze, externí API).
2. Závislost na vnitřních vrstvách: Vnější vrstvy závisí na vnitřních, nikoliv naopak. Toho se dosahuje principem inverze závislostí.
3. Zapouzdření: Každá vrstva skrývá detaily své implementace před vnějšími vrstvami.
4. Testovatelnost: Obchodní logika umístěná ve středních vrstvách nezávisí na vnějších detailech, což ji činí snadno testovatelnou v izolaci.
5. Nezávislost na rámcích: Hlavní pravidla obchodní logiky nejsou vázána na konkrétní rámce, UI nebo databáze.

Vrstvy (příklad):

• Entities: Obsahují obchodní objekty a pravidla (například třída User s obchodní logikou související s uživatelem).
• Use Cases (Interactors): Obsahují specifickou obchodní logiku aplikace (například GetUserUseCase). Koordinují interakci mezi Entities a Gateway Interfaces.
• Interface Adapters: Přizpůsobují data z externích zdrojů do formátu, který je srozumitelný pro Use Cases a Entities (například Presenters pro UI, implementace Gateway pro databáze).
• Frameworks & Drivers: Vnější vrstva obsahující frameworky (UI, databáze, webové služby).

Princip inverze závislostí hraje klíčovou roli. Vnitřní vrstvy definují rozhraní (Gateway Interfaces), a vnější vrstvy tato rozhraní implementují. To je znázorněno na následujícím schématu:

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

Směry šipek ukazují směr závislostí. Všechny závislosti směřují dovnitř, k vrstvě Entities.

V Android vývoji je Clean Architecture často implementována s použitím následujících komponent:

• UI Layer (Prezentace): Activity, Fragment, ViewModel, UI logika. Závisí na Domain Layer.
• Domain Layer (Use Cases): Obchodní logika aplikace. Nezávisí na ostatních vrstvách.
• Data Layer: Zdroj dat (sítě, databáze), repository. Implementuje rozhraní definovaná v Domain Layer.

Příklad struktury:

root
├── app
│   ├── src
│   │   └── main
│   │       └── java
│   │           └── com
│   │               └── example
│   │                   └── myapp
│   │                       ├── prezentace  // UI Layer (ViewModel, Activities, Fragments)
│   │                       │   ├── ui
│   │                       │   └── viewmodel
│   │                       ├── doména      // Domain Layer (Use Cases, Entities, Interfaces)
│   │                       │   ├── entita
│   │                       │   ├── repository  // Domain Interfaces
│   │                       │   └── usecase
│   │                       └── data        // Data Layer (Repositories, Data Sources, Mappers)
│   │                           ├── local       // Local Data Source (Room)
│   │                           ├── remote      // Remote Data Source (Retrofit)
│   │                           ├── mapper
│   │                           └── repository  // Data Implementations extending Domain Interfaces
│   └── build.gradle
└── build.gradle

Výhody:

• Testovatelnost: Obchodní logika je izolovaná a snadno testovatelná.
• Flexibilita: Snadná výměna vnějších závislostí (například přechod z Room na Realm).
• Údržba: Jasné rozdělení odpovědností usnadňuje pochopení a údržbu kódu.
• Nezávislost na technologii: Obchodní logika není vázána na specifické Android frameworky nebo knihovny.

Nevýhody:

• Složitost: Může být zpočátku složitější na pochopení a implementaci, zejména pro malé projekty.
• Více kódu: Vyžaduje psaní více tříd a rozhraní ve srovnání s jednoduššími architekturami.

Celkově je Tiszta Architektúra silným přístupem k vytváření škálovatelných a udržitelných Android aplikací, zejména pro projekty střední a velké složitosti. Podporuje vývoj kolem obchodní logiky, nikoliv kolem technických detailů.