Clean Architecture - Speaker Deck

Slide 1

Slide 1 text

Software Engineers | GDP Labs KASKUS Chat Android - Lessons Learned

Slide 2

Slide 2 text

The big names

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

4 / 67 Alistair Cockburn

Slide 5

Slide 5 text

5 / 67 Jeffrey Pallermo

Slide 6

Slide 6 text

6 / 67 James Coplien, and Trygve Reenskaug Ivar Jacobson

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

9 / 67 O’Reilly Software Architecture Conference 2017

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Software was invented to be soft

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Why is it important?

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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!

Slide 22

Slide 22 text

What’s the difference(s)?

Slide 23

Slide 23 text

23 / 67

Slide 24

Slide 24 text

24 / 67

Slide 25

Slide 25 text

25 / 67

Slide 26

Slide 26 text

26 / 67

Slide 27

Slide 27 text

27 / 67

Slide 28

Slide 28 text

28 / 67

Slide 29

Slide 29 text

29 / 67 Inversion of Control

Slide 30

Slide 30 text

30 / 67

Slide 31

Slide 31 text

31 / 67

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Idealistic vs Pragmatic

Slide 35

Slide 35 text

35 / 67 Idealistic vs Pragmatic IDEALISTIC PRAGMATIC

Slide 36

Slide 36 text

36 / 67 BEFORE AFTER Dependency Diagram

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

How components communicate

Slide 44

Slide 44 text

44 / 67 Flow of Control

Slide 45

Slide 45 text

45 / 67

Slide 46

Slide 46 text

46 / 67

Slide 47

Slide 47 text

47 / 67

Slide 48

Slide 48 text

48 / 67

Slide 49

Slide 49 text

One step further from Library vs Framework

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Overkill?

Slide 56

Slide 56 text

56 / 67

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

Bottom-up or top-down

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

Recapping...

Slide 64

Slide 64 text

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!

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

Questions/Comments? Let’s discuss! PING Android team ping@gdplabs.id

Slide 68

Slide 68 text

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