Coding Changes

Ed52a75c8cf2f4cb1c2e9d8d161ca771?s=47 Rotem Hermon
December 06, 2016

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.

Ed52a75c8cf2f4cb1c2e9d8d161ca771?s=128

Rotem Hermon

December 06, 2016
Tweet

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