Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The CLEAN cut

Filippo B
November 16, 2019

The CLEAN cut

Nowadays having a proper architecture in any software is crucial to have a healthy codebase that is manageable throughout the entire lifetime of a product. Some Android specific architectural concepts have been around for quite a while and some of them are very popular.
While evolving the platform-specific architectures has had a lot of focus from Google and gained developers' interest, less attention has been put on how to properly build architectured software from the ground up. It is now very common to have projects which rely on legacy untested pieces of software, built android-ages ago which represent a productivity bottleneck and pose a threat to code quality, software reliability, and ultimately to revenue.
CLEAN has been around in the software industry for a long period already, but just recently it has gained traction as a means to develop fully testable, scalable and reliable mobile apps.
In this talk, we'll run through a strategy about how to transition between a real-world legacy codebase towards a modularized, CLEAN architectured, unit-testable implementation of a mobile app.

Filippo B

November 16, 2019
Tweet

Other Decks in Programming

Transcript

  1. This talk won’t be covering extensively how to structure dependency

    injection. [9] [10] Different ways to carry out modularization. [4] [5] We won’t be covering build system setup, we assume just a simple gradle project. [6]
  2. Gives us easy and predictable outcomes Anyone with less familiarity

    with the code can get quickly on board Makes it easier to find bugs and fix them, reduces lead time, reduces devs burnout Reduced friction when changing or evolving framework Reduces testing efforts, reduces bugs, enables faster processes Scales with relatively low effort
  3. Brings encapsulation and on-demand delivery. It’s ideal when we have

    multiple non-core features which can be deferred. It also allows to develop for instant apps. Brings isolation and structure. It is useful to extract third-party dependencies. It allows us to extract and reuse business logic. What is preventing me from having a hybrid solution, which is good enough for my use case? I’ll lose some, I’ll win some
  4. Our build system is smart - let’s make use of

    its capabilities We can have multiple products sharing parts of the bigger picture Makes it simple to set up and maintain a suite of automated tests Breaking down the code forces us to make better choices Having boundaries between components means having better collaboration Allows us to make use of the app bundles & dynamic delivery
  5. A news reading app which can retrieve articles and news

    sources from a network source and displays them into a list.
  6. It’s the innermost layer, it does not have any dependency

    on any other layer. It’s the layer where we define the business logic, which means we define what the app does such as “Retrieve the list of news articles”.
  7. It depends on the Domain layer and the Data Sources

    layer depends on it. It embodies the Repository Pattern and offers the Domain layer a way of retrieving data from the data sources from which it orchestrates the retrieval.
  8. It depends on the Data layer of which it implements

    the interfaces. It’s the outermost layer, which means it’s very likely to change over time.
  9. It depends on the Domain layer and uses the Use

    Cases for there. It contains all the presentation related components such as ViewModel, Presenter, ...
  10. It depends on the Presentation layer from which it uses

    the presentation logic. It’s another outermost layer which is likely to change / easier to change over time..
  11. Navigation is tricky, because it always involves cross-referencing objects from

    one layer to another. How can we structure a proper navigation?
  12. The app module is responsible to implement the navigation logic.

    It has a main activity entry point which will be responsible of launching the appropriate first component.
  13. None of what we have implemented in this example is

    possible without having some form of dependency injection. DI is the core of modern android development and currently Dagger is the standard de facto for this, there are some interesting incumbents such as Koin.
  14. We have (most likely) reduced our build time, especially for

    incremental builds. We have increased the test coverage / improved testability. We are not putting all of our buy-in into any framework / library. We are making use of reactive programming as foundation of our code. We are making use of Android Architecture Components.
  15. Have everyone on board. Consider increasing the test coverage before

    proceeding to change architecture. Come up with a plan and commit to it. Encourage pair programming. Start from small, conceptually separated parts and then iterate.
  16. All of these concepts are options we have to build

    our product. We should always compare our short-term costs with the benefits in the long run. Is it worth to invest time and resources on all of this? What is the optimal trade-off between code quality and the user’s experience?
  17. [1] Clean architecture on Android by Antonio Leiva - https://antonioleiva.com/clean-architecture-android/

    [2] Adapting CLEAN architecture in Android apps by Kaushal Dhruw - https://app.pluralsight.com/library/courses/adapting-clean-architecture-android-apps/table-of-contents [3] Architecting Android..Reloaded by Fernando Cejas - https://fernandocejas.com/2018/05/07/architecting-android-reloaded/ [4] Modularization (series) by Jeroen Mols - https://jeroenmols.com/blog/2019/03/06/modularizationwhy/ [5] Modularizing Android applications by Marvin Ramin - https://www.youtube.com/watch?v=TWLkswxjSr0 [6] Build a Modular Android App Architecture (Google I/O'19) - https://www.youtube.com/watch?v=PZBg5DIzNww [7] Multiple ways of defining Clean Architecture layers by Igor Wojda - https://proandroiddev.com/multiple-ways-of-defining-clean-architecture-layers-bbb70afa5d4a [8] Better dependency management in Android Studio 3.5 with Gradle buildSrcVersions by Jean-Michel Fayard - https://proandroiddev.com/better-dependency-management-in-android-studio-3-5-with-gradle-buildsrcversions-7cd67dbaa5d4 [9] Practical guide to Dagger 2 by Gaurav Chaddha - https://android.jlelse.eu/practical-guide-to-dagger-76398948a2ea [10] That Missing Guide: How to use Dagger2 by Gabor Varadi - https://medium.com/@Zhuinden/that-missing-guide-how-to-use-dagger2-ef116fbea97
  18. Credits Presentation template by Slidesgo Icons by Flaticon Images &

    infographics by Freepik https://github.com/beraldofilippo/devfestnineteen