Clean Architecture Patterns, Practices, and #sddconf

Transcription

1 Clean Architecture Patterns, Practices, and #sddconf

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 All decisions are a tradeoff Use your best judgement

27 Domain-Centric Architecture

28 Venus Mars Earth Mercury Sun Moon Jupiter Saturn

29 Earth Mars Venus Sun Mercury Jupiter Saturn

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

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

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

33 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

34 Essential vs. Detail Space is essential Usability is essential

35 Essential vs. Detail Space is essential Usability is essential Building material is a detail Ornamentation is a detail

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

37 Essential vs. Detail Domain is essential Use cases are essential Presentation is a detail Persistence is a detail

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

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

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

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

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

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

44 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

45 Application Layer

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

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

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

49 Application Layer Implements use cases High-level application logic Knows about domain No knowledge of other layers Contains interfaces for details Users Presentation Application Domain Persistence Infrastructure Cross-Cutting Concerns Database OS Dependency

50 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

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

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

53 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

54 Commands and Queries

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

56 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

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

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

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

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

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

62 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

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

64 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

65 Functional Organization

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

67 Bedroom Bath Kitchen Entry Bedroom Dining Room Living Room Utility

68 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

69 Models Views Controllers

70 Models Customers vs Views Controllers Products Vendors

71 Content Controllers Models Scripts Views

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

73 So what?

74

75 vs

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

77 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

78 Microservices

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

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

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

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

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

84 Microservice Architectures Support Subdivide system Bounded contexts Small teams Sales Inventory Marketing HR

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

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

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

88 Code Demo

89 Where to Go Next? Martin Fowler

90 Where to Go Next? Robert C. Martin

91 Where to Go Next? Eric Evans

92 Where to Go Next? Greg Young Udi Dahan

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

94

95 Conclusion

96 Summary Focus on the inhabitants

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

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

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

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

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

102 Feedback Feedback is very important to me! One thing you liked? One thing I could improve?

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