Coding Changes

When we come to designing and writing software, we should make handling change one of our main concerns. We all pretty much do it, even if we don't usually call it that.
In this talk we'll discuss the principles of Change Driven Design. We'll also explore some software architecture methodologies that position handling change as a core concept and design principle.

Transcript

1. Coding Changes Rotem Hermon, Gigya @margolis20
2. Everything changes and nothing remains still Heraclitus
3. Everything changes
4. Everything changes Business Requirements Customers Compatitors Management
5. Everything changes Business Requirements Customers Compatitors Management Technology Stack Scale SLAs Engineers
6. Change Driven Design
7. “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
8. Shearing Layers Frank Duffy and Stewart Brand
9. “Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.” Grady Booch On Design, 2006
10. “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
11. “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
12. Change Driven Design - Principles
13. Change Driven Design - Principles • Areas of change should be contained
14. Change Driven Design - Principles • Areas of change should be contained • Things that are more likely to change should be easier to change
15. 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
16. 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
17. Change Driven Architectures
18. Hexagonal Architecture Application
19. A.K.A Ports and Adapters Pattern Devised by Alistair Cockburn Hexagonal Architecture Application
20. The Application communicates through Ports Hexagonal Architecture Application
21. (A Port is an API / Interface) Hexagonal Architecture Application
22. The Adapter is an implementation of a Port Hexagonal Architecture Application
23. The Adapter is an implementation of a Port Hexagonal Architecture Application
24. The Adapter is an implementation of a Port Testability Isolation Hexagonal Architecture Application
25. Dependencies only points inwards Hexagonal Architecture Application
26. Protects the Application against change from the outside Hexagonal Architecture Application
27. Clean Architecture Entities Use Cases Adapters Frameworks
28. By Robert C. Martin (Uncle Bob) Clean Architecture Entities Use Cases Adapters Frameworks
29. Entities are the core domain objects or methods that are least likely to change Clean Architecture Entities Use Cases Adapters Frameworks
30. Use cases are application rules. They orchestrate the Entities Clean Architecture Entities Use Cases Adapters Frameworks
31. Adapters connects between the Frameworks and the interfaces of Use Cases Clean Architecture Entities Use Cases Adapters Frameworks
32. Adapters connects between the Frameworks and the interfaces of Use Cases Clean Architecture Adapters Frameworks
33. Dependencies only points inwards Clean Architecture Entities Use Cases Adapters Frameworks
34. The only things that crosses layer boundaries are simple data structures Clean Architecture Entities Use Cases Adapters Frameworks
35. Protect the inside from changes outside Clean Architecture Entities Use Cases Adapters Frameworks
36. Isolate application layers that change differently Clean Architecture Entities Use Cases Adapters Frameworks
37. Clean Architecture Entities Use Cases Adapters Frameworks Separation of Concerns Decoupling Testability Independence
38. 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
39. 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
40. 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
41. 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
42. 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
43. 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
44. 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
45. 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
46. 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
47. 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
48. 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
49. 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
50. 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
51. 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
52. 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
53. 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
54. 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
55. Change Supporing Practices
56. Identifying Change Areas
57. “Good Enough Architecture”
58. “Good Enough Architecture” Change Ready System Complexity
59. Short Feedback Loops
60. Delegated Architectural Decision Process
61. Thank you! Rotem Hermon VP Architecture, Gigya @margolis20