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

142db55abf0e6eec31639e9abf7dd7e3?s=128

GDP Labs

July 23, 2018
Tweet

Transcript

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

    Learned
  2. The big names

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

  4. 4 / 67 Alistair Cockburn

  5. 5 / 67 Jeffrey Pallermo

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

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

  8. 8 / 67 ❏ Independent of any external agencies, e.g.

    frameworks, UI, database. ❏ Testable The Characteristics
  9. 9 / 67 O’Reilly Software Architecture Conference 2017

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

  11. Software was invented to be soft

  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
  13. 13 / 67 Keeping Options Open I/O Devices Databases Web

    systems Desktop systems Communication protocol Monolithic / Microservices Drivers Servers Frameworks UI Mediums
  14. 14 / 67 ❏ Single Responsibility Principle ❏ Open-Closed Principle

    ❏ Liskov Substitution Principle ❏ Interface Segregation Principle ❏ Dependency Inversion Principle SOLID Principle
  15. Why is it important?

  16. 16 / 67 Polymorphism - copy program same copy program

    different I/O devices
  17. 17 / 67 Polymorphism - copy program COPY CONSOLE READER

    CONSOLE WRITER <I> READER <I> WRITER <I>: interface Punch Cards Magnetic Tapes Floppy Disks https://sherpasoftware.com/blog/the-evolution-of-data-storage/ Compact Disks Flash Drives Cloud
  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
  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
  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
  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!
  22. What’s the difference(s)?

  23. 23 / 67

  24. 24 / 67

  25. 25 / 67

  26. 26 / 67

  27. 27 / 67

  28. 28 / 67

  29. 29 / 67 Inversion of Control

  30. 30 / 67

  31. 31 / 67

  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
  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
  34. Idealistic vs Pragmatic

  35. 35 / 67 Idealistic vs Pragmatic IDEALISTIC PRAGMATIC

  36. 36 / 67 BEFORE AFTER Dependency Diagram

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

  38. 38 / 67 Dependency Diagram 1st Iteration data domain presentation

    data domain presentation WHAT WE THINK WE HAVE (...and wrong) REALITY (even worse)
  39. 39 / 67 Dependency Diagram 2nd Iteration data domain presentation

    THE CORRECT ONE
  40. 40 / 67 Mapping to Clean Architecture data domain presentation

    SMACK ORMLite Android Fragment
  41. 41 / 67 Clean Architecture Independent Deployability Independent Developability Easily

    swap/upgrade third parties
  42. 42 / 67 Easily swap/upgrade third parties Upgrade SMACK 4.1.6

    to 4.1.8 (with breaking changes) Minimum usages
  43. How components communicate

  44. 44 / 67 Flow of Control

  45. 45 / 67

  46. 46 / 67

  47. 47 / 67

  48. 48 / 67

  49. One step further from Library vs Framework

  50. 50 / 67 Dependency Diagram 3rd Iteration domain data presentation

    sdk sdk-ui app-1 app-2 Third Party App Android Fragment SMACK ORMLite
  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
  52. 52 / 67 Dependency Diagram 3rd Iteration Core sdk app-1

    app-2 Third Party App SDK Boundary Core Boundary SMACK ORMLite
  53. ...or shall you? (BGM: Marry You - Bruno Mars)

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

    presentation rxjava !
  55. Overkill?

  56. 56 / 67

  57. 57 / 67 Concrete - data package - many imports

    Interface - domain package - few imports
  58. Bottom-up or top-down

  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
  60. 60 / 67 Designing Interfaces “Client should not be forced

    to depend upon interface that they do not use”
  61. ...with (things that are not) the Kardashians

  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
  63. Recapping...

  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!
  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
  66. 66 / 67 Use common sense Every system is unique

    Every system is different
  67. Questions/Comments? Let’s discuss! PING Android team ping@gdplabs.id

  68. MACHINE LEARNING CLOUD COMPUTING WEB & MOBILE COMPUTING INFORMATION SECURITY

    SCALABLE INFRASTRUCTURE bit.ly/joingdplabs jobs@gdplabs.id APPLY NOW!