Clean Architecture

142db55abf0e6eec31639e9abf7dd7e3?s=47 GDP Labs
July 23, 2018

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. 8.

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

    frameworks, UI, database. ❏ Testable The Characteristics
  2. 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
  3. 13.

    13 / 67 Keeping Options Open I/O Devices Databases Web

    systems Desktop systems Communication protocol Monolithic / Microservices Drivers Servers Frameworks UI Mediums
  4. 14.

    14 / 67 ❏ Single Responsibility Principle ❏ Open-Closed Principle

    ❏ Liskov Substitution Principle ❏ Interface Segregation Principle ❏ Dependency Inversion Principle SOLID Principle
  5. 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
  6. 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
  7. 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
  8. 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
  9. 23.
  10. 24.
  11. 25.
  12. 26.
  13. 27.
  14. 28.
  15. 30.
  16. 31.
  17. 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
  18. 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
  19. 38.

    38 / 67 Dependency Diagram 1st Iteration data domain presentation

    data domain presentation WHAT WE THINK WE HAVE (...and wrong) REALITY (even worse)
  20. 42.

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

    to 4.1.8 (with breaking changes) Minimum usages
  21. 45.
  22. 46.
  23. 47.
  24. 48.
  25. 50.

    50 / 67 Dependency Diagram 3rd Iteration domain data presentation

    sdk sdk-ui app-1 app-2 Third Party App Android Fragment SMACK ORMLite
  26. 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
  27. 52.

    52 / 67 Dependency Diagram 3rd Iteration Core sdk app-1

    app-2 Third Party App SDK Boundary Core Boundary SMACK ORMLite
  28. 55.
  29. 56.
  30. 57.

    57 / 67 Concrete - data package - many imports

    Interface - domain package - few imports
  31. 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
  32. 60.

    60 / 67 Designing Interfaces “Client should not be forced

    to depend upon interface that they do not use”
  33. 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
  34. 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!
  35. 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
  36. 66.
  37. 68.

    MACHINE LEARNING CLOUD COMPUTING WEB & MOBILE COMPUTING INFORMATION SECURITY

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