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

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
    ping@gdplabs.id
    

    View Slide

68. MACHINE LEARNING
    CLOUD COMPUTING
    WEB & MOBILE COMPUTING
    INFORMATION SECURITY
    SCALABLE INFRASTRUCTURE
    bit.ly/joingdplabs
    jobs@gdplabs.id
    APPLY
    NOW!
    

    View Slide