Clean Architecture Patterns, Practices, and #DevSum17

Transcription

1 Clean Architecture Patterns, Practices, and #DevSum17

2

3

4

5

6

7

8 About Me Independent consultant Education B.S. in Computer Science (ISU) B.A. in Philosophy (ISU) Community Public Speaker Pluralsight Author Microsoft MVP ASPInsider Open-Source Software

9 Overview 1. Clean Architecture 2. Domain-Centric Architecture 3. Application Layer 4. Commands and Queries 5. Functional Organization 6. Microservices

10 Focus Enterprise Architecture Line-of-Business Applications Modern equivalent of 3-Layer

11 Focus Generally applicable 6 Key Points Q & A

12 What is Software Architecture? High-level Structure Layers Components Relationships Source: en-us/library/ff aspx

13 Levels of Architectural Abstraction System Sub-systems Layers Components Classes Data and Methods

14 Levels of Architectural Abstraction System Sub-systems Layers Components Classes Data and Methods

15 Messy vs Clean Architecture

16 Messy vs Clean Architecture

17 Messy vs Clean Architecture

18 What Is Bad Architecture? Complex Inconsistent Incoherent Rigid Brittle Untestable Unmaintainable

19 What Is Clean Architecture? Simple Understandable Flexible Emergent Testable Maintainable

20 What Is Clean Architecture? Architecture that is designed for the inhabitants of the architecture not for the architect or the machine

21 What Is Clean Architecture? Architecture that is designed for the inhabitants of the architecture not for the architect or the machine

22 What Is Clean Architecture? Architecture that is designed for the inhabitants of the architecture not for the architect or the machine

23 What Is Clean Architecture? Architecture that is designed for the inhabitants of the architecture not for the architect or the machine

24 What Is Clean Architecture? Architecture that is designed for the inhabitants of the architecture not for the architect or the machine

25 Why Is Clean Architecture Important? Cost/benefit Minimize cost to maintain Maximize business value

26 Decisions, Decisions, Decisions Context is king

27 Decisions, Decisions, Decisions Context is king All decisions are a tradeoff

28 Decisions, Decisions, Decisions Context is king All decisions are a tradeoff Use your best judgement

29 Domain-Centric Architecture

30 Venus Mars Earth Mercury Sun Moon Jupiter Saturn

31 Earth Mars Venus Sun Mercury Jupiter Saturn

32 Venus Earth Mars Earth Mercury Sun Mars Venus Sun Mercury Moon Jupiter Saturn Jupiter Saturn Geocentric Model Heliocentric Model

33 Classic 3-layer Database-centric Architecture UI Business Logic Data Access Database Database

34 Database- vs. Domain-centric Architecture UI Presentation Business Logic Application Data Access Database Database Database Domain Database

35 The first concern of the architect is to make sure that the house is usable, it is not to ensure that the house is made of brick. Uncle Bob

36 Essential vs. Detail Space is essential Usability is essential

37 Essential vs. Detail Building material is a detail Ornamentation is a detail

38 Essential vs. Detail Domain is essential Use cases are essential

39 Essential vs. Detail Presentation is a detail Persistence is a detail

40 Database- vs. Domain-centric Architecture UI Presentation Business Logic Application Data Access Database Database Database Domain Database

41 Hexagonal Architecture answering machine adapter http feed GUI http adapter Application adapter mock telephone database adapter DB app app-to-app adapter test adapter mock database Original source:

42 Onion Architecture User Interface Application Services Domain Services Domain Database Model Application Core web service file DB Original source:

43 Clean Architecture Controllers Use Cases Database Entities Presenter Use case output port I Flow of Control Use case interactor External Interfaces Controller Use case input port I Original source:

44 It s All the Same Thing Hexagonal Onion Clean Original Source:

45 Why Use Domain-Centric Architecture? Pros Focus on essential Less coupling to details Necessary for DDD

46 Why Use Domain-Centric Architecture? Pros Focus on essential Less coupling to details Necessary for DDD Cons Change is difficult Requires extra thought Initial higher cost

47 Application Layer

48 What Are Layers? Levels of abstraction Single-Responsibility Principle Developer roles / skills Multiple implementations Varying rates of change

49 Classic 3-Layer Architecture Users UI Business Logic Data Access Database Dependency

50 Modern 4-Layer Architecture Users Presentation Application Domain Persistence Infrastructure Cross-Cutting Concerns Database OS Dependency

51 Application Layer Users Implements use cases High-level application logic Presentation Application Domain Persistence Infrastructure Cross-Cutting Concerns Database OS Dependency

52 Application Layer Users Knows about domain No knowledge of other layers Contains interfaces for details Presentation Application Domain Persistence Infrastructure Cross-Cutting Concerns Database OS Dependency

53 Layer Dependencies Users Dependency inversion Inversion of control Presentation Application Domain Persistence Infrastructure Cross-Cutting Concerns Database OS Flow of Control Dependency

54 Layer Dependencies Users Dependency inversion Inversion of control Independent deployability Flexibility and maintainability Presentation Application Domain Persistence Infrastructure Cross-Cutting Concerns Database OS Flow of Control Dependency

55 Users Presentation SalesController Application ICreateSaleCommand CreateSaleCommand IDatabaseContext IInventoryClient Domain IDateService DateService Cross-Cutting Concerns Sale Persistence DatabaseContext Database InventoryClient OS Infrastructure Composition Implements

56 Why Use an Application Layer? Pros Focus is on use cases Easy to understand Follows DIP

57 Why Use an Application Layer? Pros Focus is on use cases Easy to understand Follows DIP Cons Additional cost Requires extra thought IoC is counter-intuitive

58 Commands and Queries

59 Command-Query Separation Command Does something Should modify state Should not return a value

60 Command-Query Separation Command Does something Should modify state Should not return a value Query Answers a question Should not modify state Always returns a value

61 Command-Query Separation Command Does something Should modify state Should not return a value (ideally) Query Answers a question Should not modify state Always returns a value Avoid mixing the two!

62 CQRS Architectures Users Presentation Queries Commands Domain Data Access Persistence Database Data Flow

63 CQRS Architectures Users Presentation Queries Commands Domain Data Access Persistence Database Data Flow

64 CQRS Architectures Users Presentation Queries Commands Domain Data Access Persistence Database Data Flow

65 CQRS Architectures Users Presentation Queries Commands Domain Data Access Persistence Database Data Flow

66 CQRS Type 1 Single Database Users Presentation Queries Commands Domain Data Access Persistence Database Data Flow

67 CQRS Type 1 Single Database Users Presentation Queries Commands Domain Data Access Persistence Database Data Flow

68 CQRS Type 1 Single Database Users Presentation Queries Commands Domain Data Access Persistence Database Data Flow

69 CQRS Type 2 Read/Write Databases Users Presentation Queries Commands Domain Data Access Read Database Persistence Write Database Data Flow

70 CQRS Type 2 Read/Write Databases Users Presentation Queries Commands Domain Data Access Read Database Persistence Write Database Data Flow

71 CQRS Type 2 Read/Write Databases Users Presentation Queries Commands Domain Data Access Read Database Persistence Write Database Data Flow

72 CQRS Type 2 Read/Write Databases Users Presentation Queries Commands Domain Data Access Read Database Persistence Write Database Data Flow

73 CQRS Type 2 Read/Write Databases Users Presentation Queries Commands Domain Data Access Read Database Persistence Write Database Data Flow

74 CQRS Type 3 Event Sourcing Users Presentation Queries Commands Domain Data Access Read Database Persistence Event Store Data Flow

75 CQRS Type 3 Event Sourcing Users Events Queries Presentation Commands Domain Sale Created Item 1 Added Item 2 Added Data Access Persistence Payment Made Read Database Event Store Data Flow Sale Completed

76 CQRS Type 3 Event Sourcing Users Events Queries Presentation Commands Domain Sale Created Item 1 Added Item 2 Added Data Access Persistence Payment Made Read Database Event Store Data Flow Sale Completed

77 CQRS Type 3 Event Sourcing Users Presentation Queries Commands Domain Data Access Read Database Persistence Event Store Data Flow

78 CQRS Type 3 Event Sourcing Users Complete audit trail Point-in-time reconstruction Replay events Rebuild production database Presentation Queries Commands Domain Data Access Persistence Read Database Event Store

79 Why Use CQRS? Pros More efficient design Simpler within each stack Optimized performance

80 Why Use CQRS? Pros More efficient design Simpler within each stack Optimized performance Cons Inconsistent across stacks Type 2 is more complex Type 3 might be overkill

81 Functional Organization

82 The architecture should scream the intent of the system! Uncle Bob

83 Bedroom Bath Kitchen Entry Bedroom Dining Room Living Room Utility

84 Material Quantity Cost Appliances 5 $5,000 Cabinets 10 $2,500 Doors 15 $750 Fixtures 12 $2,400 Floors 9 $4,000 Walls 20 $10,000 Windows 8 $2,500

85 Models Views Controllers

86 Models Customers vs Views Controllers Products Vendors

87 Content Controllers Models Scripts Views

88 Content Controllers Models Scripts Views vs Customers Employees Products Sales Vendors

89 So what?

90

91 vs

92 Why Use Functional Organization Pros Spatial locality Easy to navigate Avoid vendor lock-in

93 Why Use Functional Organization Pros Spatial locality Easy to navigate Avoid vendor lock-in Cons Lose framework conventions Lose automatic scaffolding Categorical is easier at first

94 Microservices

95 Components Users UI Sales Support Inventory Business Sales Support Inventory Data Access Sales Support Inventory Database

96 Problem Domain Sales Sales Opportunity Contact Sales Person Product Sales Territory Support Support Ticket Customer Support Person Product Resolution

97 Single Domain Model Customer Sales Territory Sales Opportunity Product Support Ticket Resolution Employee

98 Single Domain Model Customer Sales Territory Sales Opportunity Product Support Ticket Resolution Employee

99 Single Domain Model Customer Sales Territory Sales Opportunity Product Support Ticket Resolution Employee

100 Single Domain Model Customer Sales Territory Sales Opportunity Product Support Ticket Resolution Employee

101 Overlapping Contexts Sales Customer Support Sales Territory Sales Opportunity Product Support Ticket Resolution Employee

102 Bounded Contexts Sales Support Contact Customer Sales Territory Sales Opportunity Product Product Support Ticket Resolution Sales Person Support Person

103 Microservice Architectures Support Sales Inventory Marketing HR

104 Microservice Architectures Support Subdivide system Sales Inventory Marketing HR

105 Microservice Architectures Support Subdivide system Light-weight APIs Sales Inventory Marketing HR

106 Microservice Architectures Support Subdivide system Light-weight APIs Small teams Sales Inventory Marketing HR

107 Microservice Architectures Support Independent Sales Inventory Marketing HR

108 Microservice Architectures Support Independent Similar to SOA Sales Inventory Marketing HR

109 Microservice Architectures Support Independent Similar to SOA Size matters Sales Inventory Marketing HR

110 Why Use Microservices? Pros Less cost for large domains Smaller teams Independence

111 Why Use Microservices? Pros Less cost for large domains Smaller teams Independence Cons Only for large domains Higher up-front cost Distributed system costs

112 Code Demo

113 Where to Go Next? Martin Fowler

114 Where to Go Next? Robert C. Martin

115 Where to Go Next? Eric Evans

116 Where to Go Next? Greg Young Udi Dahan

117 Where to Go Next? Articles Courses Presentations Source Code Videos

118

119 Conclusion

120 Summary Focus on the inhabitants

121 Summary Focus on the inhabitants Domain-centric Architecture Presentation Application Database Domain

122 Summary Focus on the inhabitants Domain-centric Architecture Application Layer Users Presentation Application Domain Persistence Infrastructure Cross-Cutting Concerns Database OS

123 Summary Focus on the inhabitants Domain-centric Architecture Application Layer Commands and Queries Queries Users Presentation Commands Domain Data Access Persistence Database

124 Summary Focus on the inhabitants Domain-centric Architecture Application Layer Commands and Queries Functional Cohesion Products Customers Vendors

125 Summary Focus on the inhabitants Domain-centric Architecture Application Layer Commands and Queries Functional Cohesion Bounded Contexts Sales Marketing Support Inventory HR

126 Feedback Very important to me! One thing you liked? One thing I could improve?

127 Contact Info Matthew Renze Data Science Consultant Renze Consulting Website: Thank You! : )