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. 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
  2. 9.

    “Architecture represents the significant design decisions that shape a system,

    where significant is measured by cost of change.” Grady Booch On Design, 2006
  3. 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
  4. 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
  5. 14.

    Change Driven Design - Principles • Areas of change should

    be contained • Things that are more likely to change should be easier to change
  6. 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
  7. 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
  8. 29.

    Entities are the core domain objects or methods that are

    least likely to change Clean Architecture Entities Use Cases Adapters Frameworks
  9. 30.

    Use cases are application rules. They orchestrate the Entities Clean

    Architecture Entities Use Cases Adapters Frameworks
  10. 31.

    Adapters connects between the Frameworks and the interfaces of Use

    Cases Clean Architecture Entities Use Cases Adapters Frameworks
  11. 32.

    Adapters connects between the Frameworks and the interfaces of Use

    Cases Clean Architecture Adapters Frameworks
  12. 34.

    The only things that crosses layer boundaries are simple data

    structures Clean Architecture Entities Use Cases Adapters Frameworks
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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