Clean Architecture Essentials - Betsson

1. Clean Architecture Essentials Ivan Paulovich
 Betsson Dev’Talk #4
 Stockholm - 23rd May 2019 @ivanpaulovich https://paulovich.net
2. Ivan Paulovich Software craftsman and GitHub addicted. 
 Interested in TDD, SOLID and 
 Clean Architecture. @ivanpaulovich
3. The “Software Architecture” Presentation Layer ASP.NET MVC and Autofac Business Layer MediatR and AutoMapper Data Layer Entity Framework and Dapper Database and Messaging SQL Server and RabbitMQ IDE and Tools Visual Studio, Resharper and .NET Framework !3 @ivanpaulovich
4. The “Software Architecture” Presentation Layer ASP.NET MVC and Autofac Business Layer MediatR and AutoMapper Data Layer Entity Framework and Dapper Database and Messaging SQL Server and RabbitMQ IDE and Tools Visual Studio, Resharper and .NET Framework !4 @ivanpaulovich Not a Software Architecture!
5. @ivanpaulovich !5 Resources I Like
6. Architecture is About Usage !6 @ivanpaulovich
7. Architecture is About Usage • The floor plan shows where people enter the building and sit. It shows where the focus is. !7 @ivanpaulovich
8. Architecture is About Usage • The floor plan shows where people enter the building and sit. It shows where the focus is. • When looking at the image it is easy to notice that it is a church floor plan. !8 @ivanpaulovich
9. Architecture is About Usage • The floor plan shows where people enter the building and sit. It shows where the focus is. • When looking at the image it is easy to notice that it is a church floor plan. How to make the software architecture scream its usage? !9 @ivanpaulovich
10. Use Cases Ticket Terminal Ticket Terminal Display movies Request movie details Print pre-ordered tickets Order tickets Customer Movie Catalog Order System Credit Processing !10 @ivanpaulovich
11. Use Cases Ticket Terminal Ticket Terminal Display movies Request movie details Print pre-ordered tickets Order tickets Customer Movie Catalog Order System Credit Processing • Use Cases are delivery independent, they show the intent of a system. !11 @ivanpaulovich
12. Use Cases Ticket Terminal Ticket Terminal Display movies Request movie details Print pre-ordered tickets Order tickets Customer Movie Catalog Order System Credit Processing • Use Cases are delivery independent, they show the intent of a system. • Use Cases are algorithms which interpret the input to generate the output data. !12 @ivanpaulovich
13. Ticket Terminal Ticket Terminal Display movies Request movie details Print pre-ordered tickets Order tickets Customer Movie Catalog Order System Credit Processing Use Cases • Use Cases are delivery independent, they show the intent of a system. • Use Cases are algorithms which interpret the input to generate the output data. • Primary and secondary actors. !13 @ivanpaulovich
14. Use Cases Implementation
 Guided by Tests • Test Cases should be the first consumers implemented. Test Cases Use Cases Core
 Layer Test Suite !14 @ivanpaulovich
15. Use Cases Implementation
 Guided by Tests • Test Cases should be the first consumers implemented. • You should design the Use Cases by following the Single Responsibility Principle. Test Cases Use Cases Core
 Layer Test Suite !15 @ivanpaulovich
16. Use Cases Implementation
 Guided by Tests • Test Cases should be the first consumers implemented. • You should design the Use Cases by following the Single Responsibility Principle. • Fake implementations should be the first delivery mechanisms implemented. Test Cases Use Cases Fake Persistence Core
 Layer Infrastructure
 Layer Test Suite !16 @ivanpaulovich
17. Use Cases Implementation
 Guided by Tests • Test Cases should be the first consumers implemented. • You should design the Use Cases by following the Single Responsibility Principle. • Fake implementations should be the first delivery mechanisms implemented. • Test Cases help you design fine grained Use Cases (Interface Segregation Principle). Test Cases Use Cases Fake Persistence Core
 Layer Infrastructure
 Layer Test Suite !17 @ivanpaulovich
18. Software Architecture “A good architecture allows major decisions to be deferred. A good architect maximizes the number of decisions not made. Uncle Bob. !18 @ivanpaulovich
19. Decoupling
 User Interface, Use Cases and Repositories TicketController IOrderTicketUseCase OrderTicket ITicketRepository SQLTicket
 Storage Core
 Layer Infrastructure
 Layer User Interface
 Layer Abstract, General,
 Stable Concrete, 
 Specific, 
 Unstable Concrete, 
 Specific, 
 Unstable Level Level !19 <<interface>> <<interface>> @ivanpaulovich
20. Plugin Architecture OrderTicket ITicketRepository SQLTicket
 Storage <<interface>> Core
 Layer Infrastructure
 Layer !20 @ivanpaulovich • The dependencies point in the direction of the abstract components.
21. Plugin Architecture OrderTicket ITicketRepository SQLTicket
 Storage <<interface>> Core
 Layer Infrastructure
 Layer 2nd !21 @ivanpaulovich • The dependencies point in the direction of the abstract components.
22. Plugin Architecture OrderTicket ITicketRepository SQLTicket
 Storage <<interface>> Core
 Layer Infrastructure
 Layer 2nd InMemoryTicket
 Storage 1st Development Order !22 @ivanpaulovich • The dependencies point in the direction of the abstract components. • First implement the simplest component version!
23. Plugin Architecture OrderTicket ITicketRepository SQLTicket
 Storage InMemoryTicket
 Storage OrderSystemTicket
 Storage Development Order • The dependencies point in the direction of the abstract components. • First implement the simplest component version! • Defer decisions. Keep the options open as long as possible! <<interface>> Core
 Layer Infrastructure
 Layer 1st 2nd 3rd !23 @ivanpaulovich
24. High Level Design SQL
 Storage Order
 Service MVC In Memory
 Storage Main Core
 Layer Infrastructure
 Layer User Interface Layer Console @ivanpaulovich • Complex systems should be made of components that are designed, implemented and tested in isolation.
25. High Level Design SQL
 Storage Order
 Service MVC In Memory
 Storage Main Core
 Layer Infrastructure
 Layer User Interface Layer Console @ivanpaulovich • Complex systems should be made of components that are designed, implemented and tested in isolation. • Some components share implementation symmetry.
26. Components Overview 1. Components are designed to fulfill the Core needs and are implemented and tested in isolation. Test Cases Infrastructure
 Layer Test Suite SQL
 Storage !26 @ivanpaulovich
27. Components Overview 1. Components are designed to fulfill the Core needs and are implemented and tested in isolation. 2. Components could be replaced, upgraded or decommissioned with minimum Core business impact. Test Cases Infrastructure
 Layer Test Suite SQL
 Storage !27 @ivanpaulovich
28. Components Overview 1. Components are designed to fulfill the Core needs and are implemented and tested in isolation. 2. Components could be replaced, upgraded or decommissioned with minimum Core business impact. 3. Good components are loosely coupled. Test Cases Infrastructure
 Layer Test Suite SQL
 Storage !28 @ivanpaulovich
29. Frameworks are Details • Application code called by frameworks should be under control. !29 @ivanpaulovich
30. Frameworks are Details • Application code called by frameworks should be under control. • Hide 3rd party libraries, use them behind core interfaces. !30 @ivanpaulovich
31. Frameworks are Details • Application code called by frameworks should be under control. • Hide 3rd party libraries, use them behind core interfaces. • The .NET Framework is a detail. !31 @ivanpaulovich
32. Frameworks are Details • Application code called by frameworks should be under control. • Hide 3rd party libraries, use them behind core interfaces. • The .NET Framework is a detail. • Keep outside the application: Reflection, Linq, Entity Framework, MVC, Data Annotations, WCF. !32 @ivanpaulovich
33. The UI is a detail TicketController IOrderTicketUseCase OrderTicket Core
 Layer User Interface
 Layer <<interface>> OrderTicket
 Request OrderTicketPresenter OrderTicket
 Response IOrderResponseHandler OrderTicket
 Model <<interface>> @ivanpaulovich !33
34. Layered Diagram Domain Application Infrastructure User Interface @ivanpaulovich !34
35. Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich !35
36. Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich !36
37. Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich !37
38. Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich !38
39. Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich !39
40. Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich !40
41. Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich !41
42. Application Unit Test Web Database Domain Primary Actors Secondary Actors @ivanpaulovich !42 Infrastructure Ports and Adapters
43. Evolutionary Architecture Definition: An evolutionary architecture supports guided, incremental changes as a first principle across multiple dimensions. !43 @ivanpaulovich
44. Sample Application Ticket Terminal Todo List App Add Todo Item List Todo Items Do Undo User Storage !44 @ivanpaulovich
45. Sample Application Ticket Terminal Todo List App Add Todo Item List Todo Items Do Undo User Storage !45 @ivanpaulovich
46. !46 ✅ Commad-Line Task management with storage on your GitHub @ivanpaulovich $ dotnet tool install -g todo https://github.com/ivanpaulovich/todo
47. Evolutionary Architecture In Action !47 Use Cases Todo List Do Undo Remove Rename Unit Tests Web API Console App In Memory File System SQL Server GitHub Persistence User Interface @ivanpaulovich
48. @ivanpaulovich Packages on the software lifetime Domain Application Infrastructure User Interface Tests Tests Core Tests Core Infrastructure 1 2 3 4
49. Wrapping up Clean Architecture • Clean Architecture is about usage and the use cases are the central organising principle. !49 @ivanpaulovich
50. Wrapping up Clean Architecture • Clean Architecture is about usage and the use cases are the central organising principle. • Use cases implementation are guided by tests. !50 @ivanpaulovich
51. Wrapping up Clean Architecture • Clean Architecture is about usage and the use cases are the central organising principle. • Use cases implementation are guided by tests. • The User Interface and Persistence are designed to fulfil the core needs (not the opposite!). !51 @ivanpaulovich
52. Wrapping up Clean Architecture • Clean Architecture is about usage and the use cases are the central organising principle. • Use cases implementation are guided by tests. • The User Interface and Persistence are designed to fulfil the core needs (not the opposite!). • Defer decisions by implementing the simplest component first. !52 @ivanpaulovich
53. Fork me on GitHub !53 Ask me 
 2 Questions! @ivanpaulovich