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