Architecture overview
I have worked in several companies, involved in many projects and have seen that many developers didn't care much about software architecture but more about frameworks, DBs, tools...
Well, that is the problem! You couldn't make high quality software without applying a good architecture regardless which framework, database, tools... are used. Maybe you're making more and more technical debts even your knowledge about Android platform / SDK is pretty good.
Over the last several years we’ve seen a whole range of ideas regarding software architecture, but I found that the clean architecture is a better one, it integrates all of these architectures into a single actionable idea. I don't talk about its principle which you can find here, but more about how we apply it into an Android project.
Anyway, some important things should be noted:
- Clean architecture produces domain-centric systems in which the domain (entities and business rules) is the core and the most important part. Please read this article to understand why domain should be the heart of system.
- Dependency rules only point inward, inner circles don't know anything about outer circles, any changes in outer circles will not make impact to inner circles. Since the domain is the most inner circles, thus it's independent of UI, DB, framework or any external agency which are in the outer circles.
- Data flow is not dependency rules. The data may go from DB through controller, enter domain and applied with some business logics, then through presenter and finally displayed on the UI. To archive this data flow without breaking dependency rules, depends on the language, for example in Java we can use interface or RxJava's Observable stream.
- Data transformation between layers: data passing across boundaries should be isolated and simple structure. For example to get data from DB or API, you have to annotate the model object with some tool specifications to make the query work, then you shouldn't modify your domain model to work with specific DB or API, this violates dependency rules since domain shouldn't care about DB or API. Therefore you should have a clean object for DB, one for API, then map them to domain model before passing it.
Depends on the project and team size, there are many solutions for modularizing an Android project. This diagram represents how we organize small to medium Android projects with clean architecture:
To support dynamic delivery features, we might need to split up the app into multiple feature modules, I will try to find a better solution later. Either presentation layer or the whole circles could be split up.