$30 off During Our Annual Pro Sale. View Details »

Clean Architecture PPP

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.

Ivan Paulovich

September 07, 2022
Tweet

More Decks by Ivan Paulovich

Other Decks in Programming

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
  26. None
  27. None
  28. None
  29. None
  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