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

Android Clean Architecture

Android Clean Architecture

Philosophy of Clean Architecture. Demo for Clean Architecture in Android by Buffer and Five Agency.

Chetan Sachdeva

October 09, 2019
Tweet

More Decks by Chetan Sachdeva

Other Decks in Programming

Transcript

  1. Shared Vocabulary • Not only does it makes it easier

    to communicate with the cook, but it gives the cook less to remember because he’s got all the diner patterns in his head. • Once you’ve got the vocabulary you can more easily communicate with other developers and inspire those who don’t know patterns to start learning them. • It also elevates your thinking about architectures by letting you think at the pattern level, not the nitty-gritty object level.
  2. Your architecture should scream the purpose of the app. -

    Robert C. Martin (Uncle Bob) More technically said, business logic should be clearly separated and independent of the framework.
  3. 4 golden rules of Architecture 1. Satisfy a multitude of

    stakeholders. 2. Encourage separation of concerns. 3. Run away from the real world (Android, DB, Internet etc). 4. Enable your components to be testable.
  4. Outer layers: Mechanisms Inner layers: Policies Dependency rule: Source code

    dependencies can only point inwards. A layer can communicate only one layer below.
  5. ① Entities • Enterprise (Uber) wide business rules. • Can

    be object with methods or set of data structures and functions. • Encapsulate most general and high level rules. • Least likely to change when something external changes (like page navigation, security etc). • For News app like NYT, entities would be Category, Article, Commercial etc.
  6. ② Use Cases • Contains Application specific business rules. •

    Encapsulates all use cases of the system. • Orchestrate data flow to and from entities. • Doesn’t change with entities or externalities (UI, DB etc). • However, changes to operation of application will affect the use cases. • Ex. Transfer money from one account to another will be “TransferMoneyUseCase”.
  7. ③ Interface Adapters • Set of adapters that convert data

    from format convenient to use cases/entities to a format convenient to an external agency (UI, DB, Web etc). • Contains MVC architecture of a GUI (Presenters, Views, Controllers etc). • Models are just data structures that are passed from controllers to use cases and then back from use cases to presenters and views.
  8. ④ Frameworks and Drivers • Tools like Database, Web Framework

    etc. • We only write the glue code here which binds the inner circles. • Details go here (UI, DB, Web etc). These are kept outside where they can do little harm.
  9. Crossing boundaries Dependency rule: Source code dependencies can only point

    inwards. Dependency Inversion Principle: We would arrange interfaces and inheritance relationships such that the source code dependencies oppose the flow of control at just the right points across the boundary.