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

Mastering Reuse: A journey into application modularization with VIPER

Mastering Reuse: A journey into application modularization with VIPER

Mobile apps development requires a great amount of time and dedication, and getting your product to market quickly with high quality is a key factor for success in today's business.
The effective reuse of application functionalities plays a very strategic role to reduce time and costs, especially when building multiple apps for similar business domains.
In this talk, Nicola will walk you through the engineering journey to application modularization, investigating the VIPER architecture and micro-services inspired design for client apps, delineating the rules of reusability to get to the definition of the (B)VIPER Module: the reusable building block of your new apps.

Nicola Zaghini

June 01, 2016
Tweet

More Decks by Nicola Zaghini

Other Decks in Programming

Transcript

  1. Grow the Business • Deliver quality and reliable solutions •

    Reduce time to market • Reduce the costs MASTERING REUSE - THE GOAL
  2. We strive to make travel better and to enable our

    customers to shape new and superior travel experiences 
 with innovative, personalised mobile and digital offerings.
  3. SOFTWARE REUSE - DEFINITION Process of implementing 
 software systems

    using existing software components or modules.
  4. SOFTWARE REUSE - GUIDELINE Reusability as a consequence of modularity.

    Identify the right module
 to master reuse.
  5. Mobile Application IDENTIFY THE MODULE Availability Service
 Booking Service
 Payment

    Service
 Check-in Service
 … Application Layer Remote Services Service Layer
  6. Remote Services Mobile Application Service Layer Availability Service
 Booking Service


    Payment Service
 Check-in Service
 … IDENTIFY THE MODULE - MICRO-SERVICE STYLE Avail. Service Booking Service Payment Service Application Layer
  7. MICRO-SERVICE STYLE - ADVANTAGES Modularity
 simple parts represented by well

    defined contracts Composition 
 final program as sum result of many simple parts Simplicity
 small and well defined parts delivering one function Testability
 promotes isolation checks and test doubles
  8. MICRO-SERVICE STYLE - INFRASTRUCTURE Versioning (semantic) Discovering and composition Lifecycle

    (scoping) Dependency Management Tool (CocoaPod, Carthage) Dependency Injection Container (Typhoon, SwiftInject, Dip)
  9. Remote Services Mobile Application Service Layer Availability Service
 Booking Service


    Payment Service
 Check-in Service
 … IDENTIFY THE MODULE - MICRO-SERVICE STYLE Avail. Service Booking Service Payment Service Application Layer
  10. Application Layer Mobile 
 Application A Mobile 
 Application B

    Mobile 
 Application C IDENTIFY THE MODULE Remote Services Avail. Service Booking Service Payment Service Application Layer Application Layer Service Layer
  11. Application Layer Mobile 
 Application A Mobile 
 Application B

    Mobile 
 Application C IDENTIFY THE MODULE Remote Services Avail. Service Booking Service Payment Service Application Layer Application Layer REUSE ?
  12. Screen based reuse.
 Each screen is a Module. • A

    Module identifies business value by fulfilling a set of user stories. • Modules have configuration and customisation capabilities (UI, Flow, BL,…) as every customer wants to be unique. • Modules are black boxes for the outside world. DEFINE REUSE
  13. DESIGN THE MODULE Flight
 Search Flight
 Availability Flight
 Summary I

    want different user interface! I want different flow! My Logic here is slightly different…
  14. View THE VIEW COMPONENT Flight
 Search Flight
 Summary Flight
 Selection

    Next Module Navigation User Interface
 No B. Logic Services Router
  15. View Model THE VIEW MODEL COMPONENT Flight
 Search Flight
 Summary

    Flight
 Selection Next Module Navigation Data Model Converter for the View Listens to View events Business Rules User Interface
 No B. Logic View Services Router
  16. THE VIEW MODEL COMPONENT Responsibilities of a single component: •

    Domain Model to View Model mapping • User interaction • Apply business rules • Service orchestration Overall, there are too many reason to change the ViewModel - Single responsibility principle violated.
  17. THE VIEW MODEL COMPONENT Data Model Converter for the View

    Listens to View events Business Rules Flight
 Search Flight
 Summary Flight
 Selection Next Module Navigation User Interface
 No B. Logic View Model View Services Router
  18. View Model THE PRESENTER COMPONENT Flight
 Search Flight
 Summary Flight


    Selection Next Module Navigation Listens to View events Business Rules Data Model Converter 
 for the View User Interface
 No B. Logic Presenter View Services Router
  19. Interactor THE INTERACTOR COMPONENT Listens to View events Data Model

    Converter 
 for the View Flight
 Search Flight
 Summary Flight
 Selection Next Module Navigation User Interface
 No B. Logic Business 
 Rules View Model Presenter View Services Router
  20. Builder THE BUILDER COMPONENT Listens to View events Data Model

    Converter 
 for the View Flight
 Search Flight
 Summary Flight
 Selection Next Module Navigation User Interface
 No B. Logic Business 
 Rules Interactor View Model Presenter View Services Router
  21. Knows concrete implementation.
 Knows how to compose the Module. Module

    exposed as Black Box 
 ViewController to the outside world. THE BUILDER COMPONENT Builder Input
 Parameters View
 Controller
  22. Builder THE BUILDER COMPONENT Listens to View events Data Model

    Converter 
 for the View Flight
 Search Flight
 Summary Flight
 Selection Next Module Navigation User Interface
 No B. Logic Business 
 Rules Interactor View Model Presenter View Services Router
  23. TESTING Easy isolation checks for all components by mocking the

    others! Interactor View Model Presenter View Router
  24. Sending information between (B)VIPER Modules … and when To Module

    is modal?
 To_Module accepts a delegate which is a component of the From_Module (usually the Presenter) Router FEW GOTCHAS From Module To Module Router provides 
 out data needed by the next Builder Builder
  25. Window Router Interactor View (VC) Presenter FEW GOTCHAS References among

    components Strong Weak Strong Weak W eak Strong Strong When the ViewController is deallocated, the whole module gets deallocated.
  26. FEW GOTCHAS • Sometimes is hard to be DRY, but

    you can use Shared Modules (don’t forget about coupling!) • Specialisation of components via Subclassing or Decoration • Handle Modules distribution and versioning via CocoaPods and use Subspecs for component granularity • Changes to the Module may sometimes touch many internal components