Wat kun je vertellen over schone architectuur…

Schone Architectuur (Clean Architecture), gepopulariseerd door Robert Martin ("Uncle Bob"), is een set principes voor het organiseren van code, gericht op het creëren van een flexibel, testbaar en gemakkelijk te onderhouden systeem.

Belangrijke ideeën:

Indeling in lagen: De code wordt verdeeld in concentrische cirkels, waarbij de binnenste lagen de bedrijfslogica bevatten en de buitenste de implementatiedetails (UI, databases, externe API's).
Afhankelijkheid van interne lagen: De buitenste lagen zijn afhankelijk van de interne lagen, maar niet andersom. Dit wordt bereikt door het principe van afhankelijkheidsomkering.
Encapsulatie: Elke laag verbergt de details van zijn implementatie voor de externe lagen.
Testbaarheid: De bedrijfslogica in de centrale lagen is onafhankelijk van de externe details, waardoor het gemakkelijk te isoleren en te testen is.
Onafhankelijkheid van frameworks: De kernregels van de bedrijfslogica zijn niet gebonden aan specifieke frameworks, UI of databases.

Lagen (voorbeeld):

Entities: Bevatten bedrijfsobjecten en regels (bijvoorbeeld de klasse User met bedrijfslogica gerelateerd aan de gebruiker).
Use Cases (Interactors): Bevatten de specifieke bedrijfslogica van de applicatie (bijvoorbeeld GetUserUseCase). Ze coördineren de interactie tussen Entities en Gateway Interfaces.
Interface Adapters: Past gegevens uit externe bronnen aan in een formaat dat begrijpelijk is voor Use Cases en Entities (bijvoorbeeld Presenters voor UI, Gateway Implementaties voor databases).
Frameworks & Drivers: De externe laag die frameworks bevat (UI, databases, webservices).

Het principe van afhankelijkheidsomkering speelt een sleutelrol. De interne lagen definiëren interfaces (Gateway Interfaces), en de externe lagen implementeren deze interfaces. Dit wordt weergegeven in het volgende schema:

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

De pijlen geven de afhankelijkheidsrichting aan. Alle afhankelijkheden wijzen naar binnen, naar de Entities-laag.

In Android-ontwikkeling wordt Clean Architecture vaak geïmplementeerd met behulp van de volgende componenten:

UI Layer (Presentation): Activity, Fragment, ViewModel, UI-logica. Afhankelijk van de Domain Layer.
Domain Layer (Use Cases): Bedrijfslogica van de applicatie. Onafhankelijk van andere lagen.
Data Layer: Gegevensbronnen (netwerken, databases), repositories. Implementeert de interfaces die in de Domain Layer zijn gedefinieerd.

Voorbeeldstructuur:

root
├── app
│   ├── src
│   │   └── main
│   │       └── java
│   │           └── com
│   │               └── example
│   │                   └── myapp
│   │                       ├── presentatie  // UI Layer (ViewModel, Activities, Fragments)
│   │                       │   ├── ui
│   │                       │   └── viewmodel
│   │                       ├── domein      // Domain Layer (Use Cases, Entities, Interfaces)
│   │                       │   ├── entitiy
│   │                       │   ├── 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

Vorteile:

Testbarkeit: Die Geschäftslogik ist isoliert und leicht testbar.
Flexibilität: Externe Abhängigkeiten können leicht ausgetauscht werden (z.B. von Room zu Realm wechseln).
Wartbarkeit: Klare Verantwortlichkeiten erleichtern das Verständnis und die Wartung des Codes.
Unabhängigkeit von Technologie: Die Geschäftslogik ist nicht an spezifische Android-Frameworks oder Bibliotheken gebunden.

Nachteile:

Komplexität: Kann anfangs komplexer sein, vor allem für kleine Projekte.
Mehr Code: Erfordert das Schreiben von mehr Klassen und Schnittstellen im Vergleich zu einfacheren Architekturen.

Insgesamt ist Clean Architecture ein leistungsstarker Ansatz für die Erstellung skalierbarer und wartbarer Android-Anwendungen, insbesondere für mittelgroße und große Projekte. Es fördert die Entwicklung um die Geschäftslogik herum, anstatt um technische Details.

Wat kun je vertellen over schone architectuur?