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

Clear_Architecture-16x9-V1.pdf

 Clear_Architecture-16x9-V1.pdf

Craig Berntson

October 16, 2018
Tweet

More Decks by Craig Berntson

Other Decks in Technology

Transcript

  1. Structured Programming •Functional Decomposition •Goto Object- Oriented Programming •Encapsulation •Inheritance

    •Polymorphism Functional Programming •Segregation of Mutability •Event Sourcing
  2. Component Cohesion Principles Reuse/Release Equivalence Common Closure Common Reuse Component

    Coupling Principles Acyclic Dependencies Stable Dependencies Stable Abstractions
  3. Component Cohesion Principles Reuse/Release Equivalence Principle (REP) The granule of

    reuse is the granule of release •The classes and modules that are formed into a component must belong to a cohesive group •Classes and modules that are grouped together in a component should be released together
  4. Component Cohesion Principles Common Closure Principle (CCP) Gather into components

    those classes that change for the same reasons and at the same time. Separate into different components those classes that change at different times and for different reasons. •Single Responsibility Principle for components •Closely associated with Open-Closed Principle
  5. Component Cohesion Principles Common Reuse Principle (CRP) Don’t force users

    of a component to depend on things they don’t need • Tells us which classes to put into a component and which ones to not keep together • Related to the Interface Segregation Principle
  6. REP Group for reusers CCP Group for maintenance CRP Split

    to avoid unneeded releases Too many unneeded releases Where in this space does your component fall?
  7. Component Coupling Principles Acyclic Dependencies Principle (ADP) Allow no cycles

    in the component dependency graph •Solves “Morning After Syndrome”
  8. Component Coupling Principles Stable Dependencies Principle (SDP) Depend on the

    direction of stability • Some components are designed to be volatile (we expect them to change). • If a component is difficult to change, it should not depend on a volatile component.
  9. Stable Dependencies Principle (SDP) Stability Metrics Fan-In The number of

    classes outside a component that depend on classes inside the component Fan-Out The number of classes inside a component that depend on classes outside the component Instability = Fan-out Fan-in + Fan-out Instability = 0 => maximum stability Instability = 1 => minimal stability
  10. Component Coupling Principles Stable Abstractions Principle (SAP) A component should

    be as abstract as it is stable •A stable component should also be abstract •An unstable component should be concrete
  11. Stable Abstractions Principle (SAP) A component should be as abstract

    as it is stable A stable component should also be abstract An unstable component should be concrete Abstractness = Number of abstract classes and interfaces in a component Number of classes in the component Abstractness = 0 => No abstraction Abstractness = 1 => Completely abstract
  12. Architecture is the shape of a software system. The form

    of that shape is the division of that system into components, the arrangement of those components, and the ways in which those components communicate with each other. “ - “Uncle” Bob Martin, Clean Architecture
  13. Good Architecture Supports Use Cases • Remember importance of behaviors

    Operation • Throughput, Scalability Development • Conway’s Law – Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure Deployment • Often an after-thought Leaves options open • Balance these concerns with a component structure that satisfies them all
  14. Clean Architecture Entities Use Cases Controllers External Interfaces UI Enterprise

    Business Rules Application Business Rules Interface Adapters Frameworks & Drivers