Android-CleanArchitecture
前言
GitHub: https://github.com/android10/Android-CleanArchitecture
Blog:
https://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/
https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
We know that writing quality software is hard and complex: It is not only about satisfying requirements, also should be robust, maintainable, testable, and flexible enough to adapt to growth and change
Clean architecture
- Independent of Frameworks.
- Testable.
- Independent of UI.
- Independent of Database.
- Independent of any external agency.
Dependency Rule: source code dependencies can only point inwards and nothing in an inner circle can know anything at all about something in an outer circle.
- Entities: These are the business objects of the application. ==> Model
- Use Cases: These use cases orchestrate the flow of data to and from the entities. Are also called Interactors. ==> data=>model
- Interface Adapters: This set of adapters convert data from the format most convenient for the use cases and entities. Presenters and Controllers belong here. ==> use Case => data
- Frameworks and Drivers: This is where all the details go: UI, tools, frameworks, etc. ==>UI
Architectural approach
It is worth mentioning that each layer uses its own data model so this independence can be reached.
Presentation Layer (Model View Presenter)
Is here, where the logic related with views and animations happens. It uses no more than a Model View Presenter (MVP from now on), but you can use any other pattern like MVC or MVVM. I will not get into details on it, but here fragments and activities are only views, there is no logic inside them other than UI logic, and this is where all the rendering stuff takes place.
Domain Layer (Regular Java Objects)
Business rules here: all the logic happens in this layer. Regarding the android project, you will see all the interactors (use cases) implementations here as well.
This layer is a pure java module without any android dependencies. All the external components use interfaces when connecting to the business objects.
Data Layer (Repository Pattern)
All data needed for the application comes from this layer through a UserRepository implementation (the interface is in the domain layer) that uses a Repository Pattern with a strategy that, through a factory, picks different data sources depending on certain conditions.
Architectural reactive approach
