The Good Architecture - Speaker Deck

Slide 1

Slide 1 text

The Good Architecture

Slide 2

Slide 2 text

Krzysztof Wawer Github: wafcio Twitter: @wafcio

Slide 3

Slide 3 text

1. Principles 2. Architectures

Slide 4

Slide 4 text

Principles

Slide 5

Slide 5 text

Principles • DRY

Slide 6

Slide 6 text

Principles • DRY • KISS

Slide 7

Slide 7 text

Principles • DRY • KISS • SOLID

Slide 8

Slide 8 text

Principles • DRY • KISS • SOLID • YAGNI

Slide 9

Slide 9 text

DRY “Don’t Repeat Yourself” Andrew Hunt and David Thomas, October 1999, The Pragmatic Bookshelf

Slide 10

Slide 10 text

DRY extras extras_allowed?(shop, invoice, order) … … … … … … … … … …

Slide 11

Slide 11 text

KISS “Keep it simple, stupid” “Keep it stupid simple” U.S. Navy in 1960, aircraft engineer Kelly Johnson

Slide 12

Slide 12 text

KISS

Slide 13

Slide 13 text

< = > LESS IS MORE

Slide 14

Slide 14 text

SOLID • SRP (Single Responsible Principle) • OCP (Open/Closed Principle) • LSP (Liskov Substitution Principle) • ISP (Interface Segregation Principle) • DIP (Dependency Inversion Principle) Robert C. Martin (Uncle Bob)

Slide 15

Slide 15 text

SRP Single Responsible Principle • 2002 • A class should have one, and only one, reason to change http://rubyblog.pro/2017/05/solid-single-responsibility-principle-by-example

Slide 16

Slide 16 text

SRP Single Responsible Principle

Slide 17

Slide 17 text

Contexts

Slide 18

Slide 18 text

OCP Open/Closed Principle • 1996 • You should be able to extend a classes behavior, without modifying it http://rubyblog.pro/2017/05/solid-open-closed-principle-by-example

Slide 19

Slide 19 text

LSP Liskov Substitution Principle • 1987 • Barbara Liskov • Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T. http://rubyblog.pro/2017/06/solid-liskov-substitution-principle

Slide 20

Slide 20 text

LSP Liskov Substitution Principle • objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program http://rubyblog.pro/2017/06/solid-liskov-substitution-principle

Slide 21

Slide 21 text

LSP anti-pattern

Slide 22

Slide 22 text

ISP Interface Segregation Principle • 1996 • Clients should not be forced to depend upon interfaces that they don't use. http://rubyblog.pro/2017/07/solid-interface-segregation-principle

Slide 23

Slide 23 text

DIP Dependency Inversion Principle • 1996 • High-level modules should not depend on low-level modules. Both should depend on abstractions • Abstractions should not depend on details. Details should depend on abstractions. http://rubyblog.pro/2017/07/solid-dependency-inversion-principle

Slide 24

Slide 24 text

SOLID Robert C. Martin (Uncle Bob)

Slide 25

Slide 25 text

YAGNI You aren't gonna need it • principle of extreme programming (XP) • XP co-founder Ron Jeﬀries has written: "Always implement things when you actually need them, never when you just foresee that you need them."

Slide 26

Slide 26 text

Architectures

Slide 27

Slide 27 text

Software Architecture Chronicles 2000s • 2003 - Domain Driven Design • 2005 - Ports & Adapters Architecture aka Hexagonal Architecture • ~2006 - CQRS & ES (Event Sourcing) • 2008 - Onion Architecture • 2012 - Clean Architecture

Slide 28

Slide 28 text

Domain Driven Design

Slide 29

Slide 29 text

Domain Driven Design

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Hexagonal Architecture

Slide 32

Slide 32 text

Hexagonal Architecture

Slide 33

Slide 33 text

Hexagonal Architecture

Slide 34

Slide 34 text

Hexagonal Architecture

Slide 35

Slide 35 text

Hexagonal Architecture

Slide 36

Slide 36 text

Hexagonal Architecture

Slide 37

Slide 37 text

Hexagonal Architecture

Slide 38

Slide 38 text

Hexagonal Architecture

Slide 39

Slide 39 text

Hexagonal Architecture

Slide 40

Slide 40 text

Hexagonal Architecture

Slide 41

Slide 41 text

Slide 42

Slide 42 text

CQS Command Query Separation • devised by Bertrand Meyer during his work on the Eiﬀel programming language • Queries: Return a result and do not change the observable state of the system (are free of side eﬀects) • Commands: Change the state of a system but do not return a value

Slide 43

Slide 43 text

Command Query Responsible Segregation 2006 Greg Young describes CQRS

Slide 44

Slide 44 text

Command Query Responsible Segregation

Slide 45

Slide 45 text

Command Query Responsible Segregation

Slide 46

Slide 46 text

Software Architecture Chronicles 2000s • 2002 - SRP (SOLID) • 2003 - Domain Driven Design • 2005 - Ports & Adapters Architecture aka Hexagonal Architecture • ~2006 - CQRS & ES (Event Sourcing) • 2008 - Onion Architecture • 2012 - Clean Architecture

Slide 47

Slide 47 text

Event-Driven Architecture • Event Notiﬁcation (Event Bus) • Event Sourcing (Event Store)

Slide 48

Slide 48 text

Event-Driven Architecture

Slide 49

Slide 49 text

Event Sourcing

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Onion Architecture https://herbertograca.com/2017/09/21/onion-architecture/

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Clean Architecture https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Slide 54

Slide 54 text

No architecture

Slide 55

Slide 55 text

@herbertograca • https://herbertograca.com • The Software Architecture Chronicles • The Containerization Chronicles • Domain Driven Design • Lean Architecture • Patterns of Enterprise Application Architecture • Patterns Principles and Practices of Domain-Driven Design • The mythical man-month

Slide 56

Slide 56 text

Q & A