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
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!