Was können Sie über saubere Architektur erzählen?

Die saubere Architektur (Clean Architecture), popularisiert von Robert Martin ("Onkel Bob"), ist eine Reihe von Prinzipien zur Organisation des Codes, die darauf abzielen, ein flexibles, testbares und wartbares System zu schaffen.

Hauptideen:

1. Schichtung: Der Code ist in konzentrische Kreise unterteilt, wobei die inneren Kreise die Geschäftslogik enthalten und die äußeren die Implementierungsdetails (UI, Datenbanken, externe APIs).
2. Abhängigkeit von den inneren Schichten: Die äußeren Schichten hängen von den inneren ab, aber nicht umgekehrt. Dies wird durch das Prinzip der Dependency Inversion erreicht.
3. Kapselung: Jede Schicht verbirgt die Details ihrer Implementierung vor den äußeren Schichten.
4. Testbarkeit: Die Geschäftslogik, die sich in den zentralen Schichten befindet, hängt nicht von externen Details ab, was sie leicht isoliert testbar macht.
5. Unabhängigkeit von Frameworks: Die wichtigsten Geschäftsregeln sind nicht an bestimmte Frameworks, UI oder Datenbanken gebunden.

Schichten (Beispiel):

• Entities: Enthalten Geschäftsobjekte und Regeln (z.B. die Klasse User mit geschäftslogikbezogenen Funktionen).
• Use Cases (Interactors): Enthalten spezifische Geschäftslogik der Anwendung (z.B. GetUserUseCase). Sie orchestrieren die Interaktion zwischen Entities und Gateway-Interfaces.
• Interface-Adapter: Passen Daten aus externen Quellen in ein Format an, das für Use Cases und Entities verständlich ist (z.B. Presenter für UI, Gateway-Implementierungen für Datenbanken).
• Frameworks & Drivers: Äußere Schicht, die Frameworks (UI, Datenbanken, Web-Services) enthält.

Das Prinzip der Dependency Inversion spielt eine Schlüsselrolle. Die inneren Schichten definieren Schnittstellen (Gateway-Interfaces), und die äußeren Schichten implementieren diese Schnittstellen. Dies wird im folgenden Schema gezeigt:

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

Die Pfeile zeigen die Richtung der Abhängigkeiten. Alle sind nach innen gerichtet, zur Schicht der Entities.

In der Android-Entwicklung wird die Clean Architecture oft mit Komponenten wie:

• UI-Schicht (Präsentation): Activity, Fragment, ViewModel, UI-Logik. Hängt von der Domänenschicht ab.
• Domänenschicht (Use Cases): Geschäftslogik der Anwendung. Hängt nicht von anderen Schichten ab.
• Daten-Schicht: Datenquellen (Netzwerke, Datenbanken), Repositories. Implementiert Schnittstellen, die in der Domänenschicht definiert sind.

Beispielstruktur:

root
├── app
│   ├── src
│   │   └── main
│   │       └── java
│   │           └── com
│   │               └── beispiel
│   │                   └── meineapp
│   │                       ├── präsentation  // UI-Schicht (ViewModel, Activities, Fragments)
│   │                       │   ├── ui
│   │                       │   └── viewmodel
│   │                       ├── domäne      // Domänenschicht (Use Cases, Entities, Interfaces)
│   │                       │   ├── entity
│   │                       │   ├── repository  // Domänen-Interfaces
│   │                       │   └── usecase
│   │                       └── daten        // Daten-Schicht (Repositories, Data Sources, Mappers)
│   │                           ├── local       // Lokale Datenquelle (Room)
│   │                           ├── remote      // Remote-Datenquelle (Retrofit)
│   │                           ├── mapper
│   │                           └── repository  // Daten-Implementierungen, die die Domänen-Interfaces erweitern
│   └── build.gradle
└── build.gradle

Vorteile:

• Testbarkeit: Die Geschäftslogik ist isoliert und leicht testbar.
• Flexibilität: Es ist einfach, externe Abhängigkeiten zu ersetzen (z.B. von Room zu Realm wechseln).
• Wartbarkeit: Klare Verantwortlichkeitsaufteilung macht den Code leichter verständlich und wartbar.
• Unabhängigkeit von Technologien: Die Geschäftslogik ist nicht an spezifische Android-Frameworks oder Bibliotheken gebunden.

Nachteile:

• Komplexität: Kann anfangs schwieriger zu verstehen und umzusetzen sein, besonders bei kleinen Projekten.
• Mehr Code: Erfordert das Schreiben von mehr Klassen und Schnittstellen im Vergleich zu einfacheren Architekturen.

Insgesamt ist die Clean Architecture ein mächtiger Ansatz, um skalierbare und wartbare Android-Anwendungen zu erstellen, insbesondere bei mittelgroßen und großen Projekten. Sie fördert die Entwicklung um die Geschäftslogik herum, nicht um technische Details.