Haben Sie Erfahrung mit Projekten, die auf reiner Architektur basieren?

Ja, es gibt.

Bei der Entwicklung mit sauberer Architektur habe ich die folgenden Schichten verwendet:

• Domänenschicht: Enthält die Geschäftslogik und Entitäten. Sie ist von anderen Schichten unabhängig. Es werden Use Cases (Interactors) und Repository-Schnittstellen definiert.
• Datenschicht: Implementiert die Schnittstellen der Repositories aus der Datenschicht. Beinhaltet die Arbeit mit Daten (Netzwerke, Datenbanken, SharedPreferences). Repositories werden häufig verwendet, um Daten aus externen Quellen in Domänenentitäten umzuwandeln.
• Präsentationsschicht: Enthält View (Fragment, Activity) und Presenter/ViewModel. Verantwortlich für die Datenanzeige und die Interaktion mit dem Benutzer. Kommuniziert mit den Use Cases aus der Domänenschicht.

Abhängigkeiten zwischen den Schichten:

• Die Präsentationsschicht hängt von der Domänenschicht ab.
• Die Datenschicht hängt von der Domänenschicht ab.

Angewandte Muster und Prinzipien in der sauberen Architektur:

• SOLID: Besonders das Prinzip der Dependency Inversion.
• Dependency Injection: Zur Vereinfachung von Tests und Abhängigkeitsmanagement (z.B. mit Dagger, Koin).
• Repository-Muster: Abstraktion über Datenquellen.
• Use Cases (Interactors): Repräsentieren konkrete Operationen in der Geschäftslogik.

Beispiel für die Projektstruktur:

├── app
│   ├── build.gradle
│   └── src
│       └── main
│           ├── java
│           │   └── com
│           │       └── beispiel
│           │           └── meineapp
│           │               ├── data // Implementierungen der Repositories, Datenquellen
│           │               │   ├── datasource
│           │               │   └── repository
│           │               ├── domain // Geschäftslogik, Use Cases, Entitäten, Repositorieschnittstellen
│           │               │   ├── entity
│           │               │   ├── repository
│           │               │   └── usecase
│           │               └── presentation // View-Schicht, ViewModel/Presenter
│           │                   ├── ui
│           │                   └── viewmodel
│           └── res

Interaktion zwischen den Schichten:

1. Die View ruft die Methode des ViewModels auf.
2. Das ViewModel ruft den entsprechenden Use Case (Geschäftslogik) auf.
3. Der Use Case greift auf die Schnittstellen der Repositories aus der Domänenschicht zu.
4. Die Implementierungen der Repositories (in der Datenschicht) holen Daten aus Quellen (Netzwerk, Datenbank).
5. Die Repositories wandeln die Daten in Domänenentitäten um und geben sie an den Use Case zurück.
6. Der Use Case verarbeitet die Daten und gibt das Ergebnis an das ViewModel zurück.
7. Das ViewModel aktualisiert die Daten, die in der View angezeigt werden.

Der Einsatz einer sauberen Architektur ermöglicht:

• Verbesserung der Testbarkeit: Jede Schicht kann isoliert getestet werden.
• Erhöhung der Wartbarkeit: Änderungen in einer Schicht wirken sich minimal auf die anderen aus.
• Steigerung der Flexibilität: Es ist einfacher, Implementierungen von Datenquellen oder UI-Ansichten zu ersetzen.
• Reduzierung der Kopplung: Trennung der Geschäftslogik von den Implementierungsdetails.