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

Clean Architecture

Clean Architecture

Clean Architecture has been around since 2012.
The term was coined by Robert C. Martin.

In this presentation, we deep dive on how KASKUS Chat Android was implemented with Clean Architecture in mind.

Video for this deck: https://youtu.be/kG3nfrdxkWU

GDP Labs

July 23, 2018
Tweet

More Decks by GDP Labs

Other Decks in Technology

Transcript

  1. Software Engineers | GDP Labs
    KASKUS Chat Android - Lessons Learned

    View Slide

  2. The big names

    View Slide

  3. 3 / 67
    https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

    View Slide

  4. 4 / 67
    Alistair Cockburn

    View Slide

  5. 5 / 67
    Jeffrey Pallermo

    View Slide

  6. 6 / 67
    James Coplien, and Trygve Reenskaug
    Ivar Jacobson

    View Slide

  7. 7 / 67
    Robert C. Martin
    https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

    View Slide

  8. 8 / 67
    ❏ Independent of any external agencies, e.g. frameworks,
    UI, database.
    ❏ Testable
    The Characteristics

    View Slide

  9. 9 / 67
    O’Reilly Software Architecture Conference 2017

    View Slide

  10. 10 / 67
    What’s the difference?
    BLOCK DIAGRAM DEPENDENCY DIAGRAM

    View Slide

  11. Software was invented to be soft

    View Slide

  12. 12 / 67
    Software was invented to be “soft”
    Soft → Easy to change
    Hard to change → Hardware
    How do we make software soft? By leaving as many options
    open as possible, for as long as possible.
    - Robert C. Martin

    View Slide

  13. 13 / 67
    Keeping Options Open
    I/O Devices Databases
    Web systems Desktop systems
    Communication protocol
    Monolithic / Microservices
    Drivers
    Servers
    Frameworks
    UI Mediums

    View Slide

  14. 14 / 67
    ❏ Single Responsibility Principle
    ❏ Open-Closed Principle
    ❏ Liskov Substitution Principle
    ❏ Interface Segregation Principle
    ❏ Dependency Inversion Principle
    SOLID Principle

    View Slide

  15. Why is it important?

    View Slide

  16. 16 / 67
    Polymorphism - copy program
    same copy program
    different I/O devices

    View Slide

  17. 17 / 67
    Polymorphism - copy program
    COPY
    CONSOLE
    READER
    CONSOLE
    WRITER

    READER

    WRITER
    : interface
    Punch
    Cards
    Magnetic
    Tapes
    Floppy Disks
    https://sherpasoftware.com/blog/the-evolution-of-data-storage/
    Compact Disks
    Flash
    Drives Cloud

    View Slide

  18. 18 / 67
    The power of polymorphism
    Martin, Robert C. 2017. Clean Architecture - A Craftsman's Guide to Software Structure and Design. Prentice Hall. Ch. 5

    View Slide

  19. 19 / 67
    The power of polymorphism
    Martin, Robert C. 2017. Clean Architecture - A Craftsman's Guide to Software Structure and Design. Prentice Hall. Ch. 5

    View Slide

  20. 20 / 67
    Benefits
    Independent Deployability
    Independent Developability
    Martin, Robert C. 2017. Clean Architecture - A Craftsman's Guide to Software Structure and Design. Prentice Hall. Ch. 5

    View Slide

  21. 21 / 67
    https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19720005243.pdf
    https://www.hq.nasa.gov/alsj/S66-05120.jpg
    ...on Apollo spacecraft design
    INDEPENDENT
    DEVELOPABILITY!

    View Slide

  22. What’s the difference(s)?

    View Slide

  23. 23 / 67

    View Slide

  24. 24 / 67

    View Slide

  25. 25 / 67

    View Slide

  26. 26 / 67

    View Slide

  27. 27 / 67

    View Slide

  28. 28 / 67

    View Slide

  29. 29 / 67
    Inversion of Control

    View Slide

  30. 30 / 67

    View Slide

  31. 31 / 67

    View Slide

  32. 32 / 67
    Martin Fowler
    Inversion of Control is a common phenomenon that you come
    across when extending frameworks.
    Indeed it's often seen as a defining characteristic of a
    framework.
    - Martin Fowler | https://martinfowler.com/bliki/InversionOfControl.html

    View Slide

  33. 33 / 67
    Martin Fowler
    As a result I think we need a more specific name for this pattern.
    Inversion of Control is too generic a term, and thus people find
    it confusing.
    As a result with a lot of discussion with various IoC advocates
    we settled on the name Dependency Injection.
    - Martin Fowler | https://martinfowler.com/articles/injection.html

    View Slide

  34. Idealistic vs Pragmatic

    View Slide

  35. 35 / 67
    Idealistic vs Pragmatic
    IDEALISTIC PRAGMATIC

    View Slide

  36. 36 / 67
    BEFORE AFTER
    Dependency Diagram

    View Slide

  37. 37 / 67
    https://github.com/android10/Android-CleanArchitecture
    DEPENDENCY DIAGRAM BLOCK DIAGRAM

    View Slide

  38. 38 / 67
    Dependency Diagram 1st Iteration
    data
    domain
    presentation
    data
    domain
    presentation
    WHAT WE THINK WE HAVE
    (...and wrong)
    REALITY
    (even worse)

    View Slide

  39. 39 / 67
    Dependency Diagram 2nd Iteration
    data
    domain
    presentation
    THE CORRECT ONE

    View Slide

  40. 40 / 67
    Mapping to Clean Architecture
    data
    domain
    presentation
    SMACK
    ORMLite
    Android
    Fragment

    View Slide

  41. 41 / 67
    Clean Architecture
    Independent Deployability
    Independent Developability
    Easily swap/upgrade third parties

    View Slide

  42. 42 / 67
    Easily swap/upgrade third parties
    Upgrade SMACK 4.1.6 to 4.1.8
    (with breaking changes)
    Minimum usages

    View Slide

  43. How components communicate

    View Slide

  44. 44 / 67
    Flow of Control

    View Slide

  45. 45 / 67

    View Slide

  46. 46 / 67

    View Slide

  47. 47 / 67

    View Slide

  48. 48 / 67

    View Slide

  49. One step further from Library vs Framework

    View Slide

  50. 50 / 67
    Dependency Diagram 3rd Iteration
    domain
    data
    presentation
    sdk
    sdk-ui
    app-1 app-2
    Third Party
    App
    Android
    Fragment
    SMACK
    ORMLite

    View Slide

  51. 51 / 67
    Dependency Diagram 3rd Iteration
    domain
    data
    presentation
    sdk
    sdk-ui
    app-1 app-2
    Third Party
    App
    SDK
    Boundary
    Core
    Boundary
    SMACK
    ORMLite

    View Slide

  52. 52 / 67
    Dependency Diagram 3rd Iteration
    Core
    sdk
    app-1 app-2
    Third Party
    App
    SDK
    Boundary
    Core
    Boundary
    SMACK
    ORMLite

    View Slide

  53. ...or shall you? (BGM: Marry You - Bruno Mars)

    View Slide

  54. 54 / 67
    Idealistic vs Pragmatic
    build.gradle (domain)
    data
    domain
    presentation
    rxjava
    !

    View Slide

  55. Overkill?

    View Slide

  56. 56 / 67

    View Slide

  57. 57 / 67
    Concrete
    - data package
    - many imports
    Interface
    - domain package
    - few imports

    View Slide

  58. Bottom-up or top-down

    View Slide

  59. 59 / 67
    Designing Interfaces
    1. Create concrete class first
    2. Adjust the interface
    3. Unit test
    1. Create interface based on req
    2. Unit test
    3. Implement concrete class
    Bottom-Up Top-Down
    4. Refactor
    0. Read Open-Source Code

    View Slide

  60. 60 / 67
    Designing Interfaces
    “Client should not be forced to depend
    upon interface that they do not use”

    View Slide

  61. ...with (things that are not) the Kardashians

    View Slide

  62. 62 / 67
    Keeping up with (things that are not) the Kardashians
    https://developer.android.com/jetpack/
    RxJava 1.0 18 Nov 2014 (support ends 31 Mar 2018)
    RxJava 2.0 29 Oct 2016

    View Slide

  63. Recapping...

    View Slide

  64. 64 / 67
    ❏ {Hexagonal, Onion, DCE, BCE, Clean} Architecture
    ❏ Block vs Dependency Diagram
    ❏ Software was invented to be soft
    ❏ Dependency Inversion / Inversion of Control / DI
    ❏ Independent {Deployability, Developability}
    ❏ Easily swap/upgrade third parties
    ❏ Flow of Control
    ❏ Library vs Framework
    ❏ SDK!

    View Slide

  65. 65 / 67
    ❏ Idealistic vs Pragmatic
    ❏ One Interface One Implementation
    ❏ Designing Interfaces
    ❏ Read open-source code
    ❏ Bottom-Up vs Top-Down
    ❏ Interface Segregation Principle
    ❏ Keep up with (things that are not) the Kardashians
    ❏ What we learn/decide today will be obsolete tomorrow

    View Slide

  66. 66 / 67
    Use common sense
    Every system is unique
    Every system is different

    View Slide

  67. Questions/Comments? Let’s discuss!
    PING Android team
    [email protected]

    View Slide

  68. MACHINE LEARNING
    CLOUD COMPUTING
    WEB & MOBILE COMPUTING
    INFORMATION SECURITY
    SCALABLE INFRASTRUCTURE
    bit.ly/joingdplabs
    [email protected]
    APPLY
    NOW!

    View Slide