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

Who needs an architecture for android applicat...

Erik Jhordan Rey
June 15, 2016
700

Who needs an architecture for android applications development?

Clean Architecture

Erik Jhordan Rey

June 15, 2016
Tweet

Transcript

  1. Architecture #By Martin Fowler “Architecture as a word we use

    when we want to talk about design but want to puff it up to make it sound important.” “In most successful software projects, the expert developers working on that project have a shared understanding of the design system design. This shared understanding is called ‘architecture.’ This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers.” #By Ralph Johnson
  2. Entities Use Cases Controllers Gateways Presenters Devices W eb UI

    DB External Interfaces Frameworks and drivers Interface Adapters Business Rules Domain Logic
  3. Dependency Rule Entities encapsulate Enterprise wide business rules. An entity

    can be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise.
  4. Entities Entities encapsulate Enterprise wide business rules. An entity can

    be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise.
  5. Uses Cases The software in this layer contains application specific

    business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.
  6. Interface Adapters The software in this layer is a set

    of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or the Web.
  7. Frameworks and Drivers The outermost layer is generally composed of

    frameworks and tools such as the Database, the Web Framework, etc. Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards. This layer is where all the details go. The Web is a detail. The database is a detail. We keep these things on the outside where they can do little harm.
  8. Model View Controller Model What to display? View How it’s

    displayed? Controller Formatting the model for display and handling events like user input. #MVC
  9. Model View Presenter #MVP The MVP pattern allows separate the

    presentation layer from the logic, so that everything about how the interface works is separated from how we represent it on screen. Ideally the MVP pattern would achieve that same logic might have completely different and interchangeable views.
  10. Model View ViewModel Is an architectural approach used to abstract

    the state and behaviour of a view, which allows us to separate the development of the UI from the business logic. #MVVM
  11. • These patterns try to solve the same problems •

    Both patterns are going to improve code quality and testability. • Think about these patterns and use the one you understand better.
  12. Repository Pattern Use a repository to separate the logic that

    retrieves the data and maps it to the entity model from the business logic that acts on the model. The business logic should be agnostic to the type of data that comprises the data source layer. For example, the data source layer can be a database, a SharePoint list, or a Web service. #msdn
  13. Clean Architecture Principles • The Dependency Rule • Presentation is

    decoupled from domain • Domain module can be a layer module. • Data layer decouples the rest of the app • Independent of Frameworks. • Independent of UI • Independent of Database • Entities Representing Enterprise Rules
  14. View Presenter Activity Fragment Use Case Use Case Use Case

    Domain Model Data Source Implementation Repository Repository Data Source Data Source Data Source Implementation Presentation Layer Domain Layer Data Layer
  15. Clean Architecture Conclusion Conforming to these simple rules is not

    hard, and will save you a lot of headaches going forward. By separating the software into layers, and conforming to The Dependency Rule, you will create a system that is intrinsically testable, with all the benefits that implies. When any of the external parts of the system become obsolete, like the database, or the web framework, you can replace those obsolete elements with a minimum of fuss. #Uncle Bob
  16. #OO Principles Favor composition over inheritance Program to interfaces, not

    implementations Classes should be open for extension but closed for modifications Strive for loosely coupled design between objects that interact Depend on abstractions do not depend on concrete class
  17. #SOLID Single responsibility principle Open / Closed principle Liskov substitution

    principle Interface segregation principle Dependency inversion principle
  18. Further Reading • My Personal Blog https://erikcaffrey.github.io • Android Clean

    Architecture by Fernando Cejas https://github.com/android10/Android-CleanArchitecture • Clean Architecture by Uncle Bob https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html • Rosie Android Framework for Clean Architecture by Karumi https://github.com/Karumi/Rosie
  19. Erik Jhordan González Reyes Android Developer +Erik Jhordan Rey Caffrey

    @ErikJhordan_Rey erikcaffrey erikcaffrey.github.io