Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Coding Changes

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.

Rotem Hermon

December 06, 2016
Tweet

More Decks by Rotem Hermon

Other Decks in Programming

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