Slide 1

Slide 1 text

Coding Changes Rotem Hermon, Gigya @margolis20

Slide 2

Slide 2 text

Everything changes and nothing remains still Heraclitus

Slide 3

Slide 3 text

Everything changes

Slide 4

Slide 4 text

Everything changes Business Requirements Customers Compatitors Management

Slide 5

Slide 5 text

Everything changes Business Requirements Customers Compatitors Management Technology Stack Scale SLAs Engineers

Slide 6

Slide 6 text

Change Driven Design

Slide 7

Slide 7 text

“Our basic argument is that there isn't any such thing as a building. A building properly conceived is several layers of longevity of built components.” Architect Frank Duffy

Slide 8

Slide 8 text

Shearing Layers Frank Duffy and Stewart Brand

Slide 9

Slide 9 text

“Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.” Grady Booch On Design, 2006

Slide 10

Slide 10 text

“One begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a design decision from the others.” David L. Parnas On the criteria To Be Used in Decomposing Systems into Modules, 1972

Slide 11

Slide 11 text

“The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is.” Robert C. Martin The Stable Dependencies Principle, 1997

Slide 12

Slide 12 text

Change Driven Design - Principles

Slide 13

Slide 13 text

Change Driven Design - Principles ● Areas of change should be contained

Slide 14

Slide 14 text

Change Driven Design - Principles ● Areas of change should be contained ● Things that are more likely to change should be easier to change

Slide 15

Slide 15 text

Change Driven Design - Principles ● Areas of change should be contained ● Things that are more likely to change should be easier to change ● Things that are less likely to change should not depend on things that are likely to change

Slide 16

Slide 16 text

Change Driven Design - Principles ● Areas of change should be contained ● Things that are more likely to change should be easier to change ● Things that are less likely to change should not depend on things that are likely to change ● Change should entail extending the system rather than refactoring

Slide 17

Slide 17 text

Change Driven Architectures

Slide 18

Slide 18 text

Hexagonal Architecture Application

Slide 19

Slide 19 text

A.K.A Ports and Adapters Pattern Devised by Alistair Cockburn Hexagonal Architecture Application

Slide 20

Slide 20 text

The Application communicates through Ports Hexagonal Architecture Application

Slide 21

Slide 21 text

(A Port is an API / Interface) Hexagonal Architecture Application

Slide 22

Slide 22 text

The Adapter is an implementation of a Port Hexagonal Architecture Application

Slide 23

Slide 23 text

The Adapter is an implementation of a Port Hexagonal Architecture Application

Slide 24

Slide 24 text

The Adapter is an implementation of a Port Testability Isolation Hexagonal Architecture Application

Slide 25

Slide 25 text

Dependencies only points inwards Hexagonal Architecture Application

Slide 26

Slide 26 text

Protects the Application against change from the outside Hexagonal Architecture Application

Slide 27

Slide 27 text

Clean Architecture Entities Use Cases Adapters Frameworks

Slide 28

Slide 28 text

By Robert C. Martin (Uncle Bob) Clean Architecture Entities Use Cases Adapters Frameworks

Slide 29

Slide 29 text

Entities are the core domain objects or methods that are least likely to change Clean Architecture Entities Use Cases Adapters Frameworks

Slide 30

Slide 30 text

Use cases are application rules. They orchestrate the Entities Clean Architecture Entities Use Cases Adapters Frameworks

Slide 31

Slide 31 text

Adapters connects between the Frameworks and the interfaces of Use Cases Clean Architecture Entities Use Cases Adapters Frameworks

Slide 32

Slide 32 text

Adapters connects between the Frameworks and the interfaces of Use Cases Clean Architecture Adapters Frameworks

Slide 33

Slide 33 text

Dependencies only points inwards Clean Architecture Entities Use Cases Adapters Frameworks

Slide 34

Slide 34 text

The only things that crosses layer boundaries are simple data structures Clean Architecture Entities Use Cases Adapters Frameworks

Slide 35

Slide 35 text

Protect the inside from changes outside Clean Architecture Entities Use Cases Adapters Frameworks

Slide 36

Slide 36 text

Isolate application layers that change differently Clean Architecture Entities Use Cases Adapters Frameworks

Slide 37

Slide 37 text

Clean Architecture Entities Use Cases Adapters Frameworks Separation of Concerns Decoupling Testability Independence

Slide 38

Slide 38 text

IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 39

Slide 39 text

By Juval Lowy and the IDesign team IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 40

Slide 40 text

Client layer. Can be presentation, API or another system IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 41

Slide 41 text

Managers encapsulate workflows. They orchestrate use cases IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 42

Slide 42 text

Managers are lightweight. They should be easy to change IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 43

Slide 43 text

Engines encapsulates business rules and activities IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 44

Slide 44 text

Resource access encapsulates resources. They expose business terms, not CRUD IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 45

Slide 45 text

A Resource can be a Database or an external API IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 46

Slide 46 text

Utilities are common infrastructure (message bus, logging) IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 47

Slide 47 text

Managers can use several Engines IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 48

Slide 48 text

Resource Access can be shared across Managers and Engines IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 49

Slide 49 text

Only data crosses layers and services. Not logic IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 50

Slide 50 text

No call sideways! IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 51

Slide 51 text

Except asynchronous / queued calls between Managers IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 52

Slide 52 text

Each service encapsulates an area of change IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 53

Slide 53 text

The further down you go, things are harder to change IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 54

Slide 54 text

Changing or adding use cases should mean changing Managers and extending Engines / RAs IDesign Method Client Business Logic Resource Access Resource Resource Access A Manager A Client A Client B Engine A Manager B Engine B Resource Access B Resource A Resource B Utilities Util A Util B

Slide 55

Slide 55 text

Change Supporing Practices

Slide 56

Slide 56 text

Identifying Change Areas

Slide 57

Slide 57 text

“Good Enough Architecture”

Slide 58

Slide 58 text

“Good Enough Architecture” Change Ready System Complexity

Slide 59

Slide 59 text

Short Feedback Loops

Slide 60

Slide 60 text

Delegated Architectural Decision Process

Slide 61

Slide 61 text

Thank you! Rotem Hermon VP Architecture, Gigya @margolis20