Clean Architecture PPP

An introduction to Clean Architecture Style with focus on Principles, Patterns and Practices. You will see how Software Architecture could be defined not only by its structure but by the way it is developed and the principles behind its decisions.

We will show that Hexagonal Architecture Style gives you the initial guidelines on decoupling business logic from external dependencies. Later we will show how the Use Cases as a central organizing structure is the signature of a Clean Architecture implementation.

Transcript

1. Ivan Paulovich - Sep 7, 2022 Clean Architecture Principles, Patterns & Practices
2. @ivanpaulovich
3. Agenda Hexagonal Architecture Style Clean Architecture Style Testing Strategies Pitfalls Q&A
4. Hexagonal Architecture Style Hexagonal Architecture Style Principles Dependency Inversion Principle Patterns Ports and Adapters Pattern Practices Test-Driven Development @ivanpaulovich
5. Dependency Inversion Principle • High-level modules should not depend on low-level modules. • Both should depend on abstractions. • Abstractions should not depend on details. • Details should depend on abstractions. @ivanpaulovich
6. Ports and Adapters Pattern Core Cloud E-mail Noti fi cation In Memory 
 Messaging 
 Database In Memory 
 Persistence 
 MS SQL Persistence Web App Unit Tests User Interface @ivanpaulovich Noti fi cation
7. Ports • Ports are the interfaces exposed by the application. • Ports are highly abstract. • Examples of ports are: • Use Cases signatures; • Required dependencies. @ivanpaulovich
8. Ports @ivanpaulovich
9. • Adapters implement Ports. • Adapters are highly concrete. • Adapters are very speci fi c. • Adapters could be a Primary or Secondary Actors. Adapters @ivanpaulovich
10. • Examples of Adapters are: • Web App Layer; • Unit Tests; • Data access implementations; • Infrastructure components. Adapters @ivanpaulovich
11. Adapters @ivanpaulovich
12. Application Unit Test Web Database Domain Primary Actors Secondary Actors @ivanpaulovich 12 Infrastructure Ports and Adapters
13. @ivanpaulovich What’s TDD? A practice to use tests to guide the software implementation. Boosts the con fi dence to change and to deploy software. Works as a team communication technique.
14. http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd @ivanpaulovich The Rules of TDD 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is suf fi cient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is suf fi cient to pass the one failing unit test.
15. Red-Green-Refactor Red Gren Refactor Write just enough code to pass the test Improve the code without changing its behaviour Write a test and watch it fail TDD Cycle @ivanpaulovich
16. A Web of Objects @ivanpaulovich
17. ? ? ? Test Expectations @ivanpaulovich Design for Testing
18. The First Test Deposit 
 Use Case Customer 
 Repository Account Repository Test Expectations @ivanpaulovich
19. The Walking Skeleton Deposit 
 Use Case Customer 
 Repository Account Repository Fakes User 
 Interface @ivanpaulovich
20. Deposit 
 Use Case Customer 
 Repository Account Repository Fakes User 
 Interface Integration Tests s Account Repository Test Customer 
 Repository SQL Component @ivanpaulovich
21. Hexagonal vs. Clean Architecture Style Hexagonal Architecture Style Principles Dependency Inversion Principle Patterns Ports and Adapters Pattern Practices Test-Driven Development @ivanpaulovich
22. Hexagonal Architecture Style Clean Architecture Style Also Requires Principles Dependency Inversion Principle Stable Dependencies Principle; Stable Abstractions Principle. Patterns Ports and Adapters Pattern Use Cases as central organising structure; Pluggable user interface. Practices Test-Driven Development Hexagonal vs. Clean Architecture Style @ivanpaulovich
23. Each of these architectures produce systems that are: • Independent of Frameworks. • Testable. • Independent of UI. • Independent of Database. • Independent of any external agency. https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html “ @ivanpaulovich
24. Entities Entities Clean Architecture Entities Use Cases Controllers Gatew ays Presenters D evices W eb UI DB External Interfaces @ivanpaulovich • Abstractness increases with stability. • Modules depend in the direction of stability. • Classes that change together are packaged together. Principles
25. Entities Use Cases Controllers Presenters Gateways Devices UI DB Web External Interfaces Abstract,
 General,
 Stable,
 Consistent Concrete,
 Speci fi c, 
 Unstable, Inconsistent Level Clean Architecture @ivanpaulovich
30. Use Case • It is an application entry point. • Shows the usage. @ivanpaulovich
31. Use Cases • Use Cases show the intent of a system. • Use Cases are delivery independent. • Use Cases are algorithms that interpret the input to generate the output data. • Use Cases diagrams highlight the Primary and secondary actors. 31 @ivanpaulovich
32. Controller Use Case Core User Interface @ivanpaulovich Request Response Input Output • Abstract • General • Stable • Consistent • Concrete • Speci fi c • Unstable • Inconsistent
33. Deposit Use Case @ivanpaulovich
34. Pluggable User Interface • Your Core abstractions should support be the same even if your application runs on a Web server or in a Console Terminal. • Ideally your User Interface is a plugin to your application. • The Core abstractions de fi ne expectations on what the UI should look like. @ivanpaulovich
35. The “Presenter” Approach @ivanpaulovich
36. The “Presenter” Approach @ivanpaulovich
37. The “Presenter” Approach @ivanpaulovich
38. Testing Strategies @ivanpaulovich
39. Services Controllers Repositories Use Cases Domain External APIS Database Single Page Application HTTP TCP HTTP The Typical Software Structure @ivanpaulovich
40. A Wallet Application Deposit Withdraw Transfer Close Account Open Account Database Persistence Exchange Service User Interface Exchange Rates API In Memory SQL In Memory Security @ivanpaulovich
41. Services Controllers Repositories Use Cases Domain Unit Tests Fake API Fake DB Unit Tests @ivanpaulovich
42. @ivanpaulovich
43. Services Controllers Repositories Use Cases Domain Component 
 Tests HTTP Component Tests @ivanpaulovich Fake API Fake DB
44. @ivanpaulovich
45. @ivanpaulovich
46. Services Controllers Repositories Use Cases Domain External APIS Database TCP HTTP Integration Tests Integration Tests @ivanpaulovich
47. @ivanpaulovich
48. Application External APIS Database End to End 
 Tests HTTP TCP HTTP End to End Tests @ivanpaulovich
49. @ivanpaulovich
50. @ivanpaulovich
51. What kind of test should I write first? Test Kind Criteria Unit Tests When use cases are complex and requires learning. Integration Tests When integration protocols are critical and complex. Component Tests When API Contracts need to be designed then shared. End To End Tests “Never”. @ivanpaulovich
52. Tests Writing Considerations Think about assertion. It should be short. Each test has a single “System Under Test”. Mocks are less valuable than fakes since only fakes could run in production. @ivanpaulovich
53. Common Misconceptions Test-First does not mean “Write the complete test then write the code.” Test-First means “Write a little bit of the test then write a piece of the production code.” @ivanpaulovich
54. Clean Architecture Pitfalls. 
 When it starts to break. @ivanpaulovich
55. Hard to scale out • It takes time for a squad to learn the overall structure. • It takes time for a squad to learn how to decouple from frameworks. • It takes time to write better tests without Moq. • It worked for me to have a “Unicorn” project that we could get inspired by. @ivanpaulovich
56. Too much boilerplate • We do write boilerplate around public interfaces. • We do write boilerplate around implementing fakes components. • We do write boilerplate around validation and common frameworks. @ivanpaulovich
57. Boilerplate vs Frameworks • Larger “Clean Architecture” implementations tend to have lots of boilerplate. • At this advanced level a developer starts thinking about building a “framework” to reduce it. He might consider: 1. Design the framework as part of the existing application. 2. Use frameworks and libraries of the shelf. 3. Or a mix of both. @ivanpaulovich
58. Where to put exception handling? • Exception handling should be implemented on adapters. • Focus on exception handling on I/O. @ivanpaulovich
59. Validation • Validation without frameworks are painful to maintain. • FluentValidation is very helpful. • FluentValidation can be used following the Ports and Adapters pattern. @ivanpaulovich
60. It is not Clean Architecture when… @ivanpaulovich
61. @ivanpaulovich https://github.com/ivanpaulovich/clean-architecture-manga Further references:
62. Q&A @ivanpaulovich