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
   

   View Slide

2. Everything changes and nothing remains still
   Heraclitus
   

   View Slide

3. Everything changes
   

   View Slide

4. Everything changes
   Business
   Requirements
   Customers
   Compatitors
   Management
   

   View Slide

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

   View Slide

6. Change Driven Design
   

   View Slide

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
   

   View Slide

8. Shearing Layers
   Frank Duffy and
   Stewart Brand
   

   View Slide

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

   View Slide

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
    

    View Slide

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
    

    View Slide

12. Change Driven Design - Principles
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

17. Change Driven Architectures
    

    View Slide

18. Hexagonal Architecture
    Application
    

    View Slide

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

    View Slide

20. The Application communicates through Ports
    Hexagonal Architecture
    Application
    

    View Slide

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

    View Slide

22. The Adapter is an implementation of a Port
    Hexagonal Architecture
    Application
    

    View Slide

23. The Adapter is an implementation of a Port
    Hexagonal Architecture
    Application
    

    View Slide

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

    View Slide

25. Dependencies only points inwards
    Hexagonal Architecture
    Application
    

    View Slide

26. Protects the Application against change
    from the
    outside
    Hexagonal Architecture
    Application
    

    View Slide

27. Clean Architecture
    Entities
    Use Cases
    Adapters
    Frameworks
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

33. Dependencies only points inwards
    Clean Architecture
    Entities
    Use Cases
    Adapters
    Frameworks
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

55. Change Supporing Practices
    

    View Slide

56. Identifying Change Areas
    

    View Slide

57. “Good Enough Architecture”
    

    View Slide

58. “Good Enough Architecture”
    Change Ready
    System Complexity
    

    View Slide

59. Short Feedback Loops
    

    View Slide

60. Delegated Architectural Decision Process
    

    View Slide

61. Thank you!
    Rotem Hermon
    VP Architecture, Gigya
    @margolis20
    

    View Slide