Clear_Architecture-16x9-V1.pdf

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
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