Clear_Architecture-16x9-V1.pdf

 Clear_Architecture-16x9-V1.pdf

008c45c68ff49184796deda5faca4126?s=128

Craig Berntson

October 16, 2018
Tweet

Transcript

  1. Clean Architecture Craig Berntson

  2. Overview COMPONENTS ARCHITECTURE PRINCIPLES ARCHITECTURE CLEAN ARCHITECTURE DETAILS

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

    •Polymorphism Functional Programming •Segregation of Mutability •Event Sourcing
  4. SOLID Principles Single Responsibility Open-Closed Liskov Substitution Interface Segregation Dependency

    Inversion
  5. Components

  6. Component Cohesion Principles Reuse/Release Equivalence Common Closure Common Reuse Component

    Coupling Principles Acyclic Dependencies Stable Dependencies Stable Abstractions
  7. 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
  8. 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
  9. 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
  10. 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?
  11. Component Coupling Principles Acyclic Dependencies Principle (ADP) Allow no cycles

    in the component dependency graph •Solves “Morning After Syndrome”
  12. Acyclic Dependencies Principle (ADP) Main View Presenters Database Interactors Entities

    Controllers Authorizer
  13. Acyclic Dependencies Principle (ADP) Main View Presenters Database Interactors Entities

    Controllers Authorizer Permissions
  14. 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.
  15. Stable Dependencies Principle (SDP) A

  16. 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
  17. 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
  18. 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
  19. Stable Abstractness Principle (SAP) Stability Abstactness (0,1) (0,0) (1,1) (1,0)

  20. Architecture

  21. 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
  22. Purpose of Architecture Minimize lifetime cost & maximize programmer productivity

    Development Deployment Operation Maintenance
  23. 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
  24. None
  25. Boundaries Business Rules Database Interface Database Access Database

  26. Boundaries Business Rules GUI Database

  27. Clean Architecture Entities Use Cases Controllers External Interfaces UI Enterprise

    Business Rules Application Business Rules Interface Adapters Frameworks & Drivers
  28. Details

  29. Details Database Performance Web Frameworks

  30. Review COMPONENTS ARCHITECTURE PRINCIPLES ARCHITECTURE CLEAN ARCHITECTURE DETAILS

  31. @craigber architecture@craigberntson.com