Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Clean Architecture Essentials - SSC

Clean Architecture Essentials - SSC

Ivan Paulovich

November 13, 2019
Tweet

More Decks by Ivan Paulovich

Other Decks in Programming

Transcript

  1. Agenda • The “Software Architecture” • Introduction to Clean Architecture

    • Plugin Argument • Use Cases Implementation Guided By Tests • Ports and Adapters Explained • The User Interface is a Detail • Frameworks are Details • Sample Application • Wrapping up • References
  2. Ivan Paulovich Agile Software Developer, Tech Lead, 20+ GitHub projects

    about Clean Architecture, SOLID, DDD and TDD. 
 Speaker/Streamer. @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 4 @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 5 @ivanpaulovich Not a Software Architecture!
  5. Clean Architecture • Use Cases as central organising structure. •

    Follows the Ports and Adapters pattern (Hexagonal Architecture). • Implementation is guided by tests. • Decoupled from technology details. • Lots of Principles (SAP, SDP, SOLID..) • Pluggable User Interface @ivanpaulovich
  6. 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. • Show the intent of a system. • Use Cases are algorithms that interpret the input to generate the output data. • Primary and secondary actors. 8 @ivanpaulovich
  7. Business v Primary Actors @ivanpaulovich 9 Ports and Adapters Cloud

    Messaging UI In Memory Persistence Tests In Memory Messaging SQL Secondary Actors
  8. @ivanpaulovich Abstract ⭐ ⭐ 
 General ⭐ ⭐
 Stable ⭐

    ⭐ Concrete ⭐ ⭐ 
 Inconsistent ⭐ ⭐
 Specific ⭐ ⭐ Abstractions and Stability Principles Concrete ⭐ ⭐ 
 Consistent ⭐ 
 Specific ⭐
  9. Entities Entities Clean Architecture Entities Use Cases Controllers Gatew ays

    Presenters D evices W eb UI DB External Interfaces @ivanpaulovich •Abstractness increases with stability. •Depend in the direction of stability. •Classes that change together are packaged together.
  10. Entities Use Cases Controllers Presenters Gateways Devices UI DB Web

    External Interfaces Abstract, General, 
 Stable, Consistent Concrete, Specific, 
 Unstable, Inconsistent Level Clean Architecture @ivanpaulovich
  11. Plugin Architecture TicketController IOrderTicketUseCase OrderTicket ITicketRepository SQLTicket Storage Core
 Layer

    Infrastructure
 Layer User Interface
 Layer Abstract, General,
 Stable Concrete, 
 Specific, 
 Unstable Concrete, 
 Specific, 
 Unstable Level Level 15 <<interface>> <<interface>> @ivanpaulovich
  12. Software Architecture “A good architecture allows major decisions to be

    deferred. 
 A good architect maximizes the number of decisions not made. Uncle Bob. 16 @ivanpaulovich
  13. Plugin Architecture OrderTicket ITicketRepository SQL Server / NoSQL <<interface>> Core

    Layer Infrastructure Layer 17 @ivanpaulovich • The dependencies point in the direction of the abstract components.
  14. Core Layer Infrastructure Layer Plugin Architecture OrderTicket ITicketRepository SQL Server

    / NoSQL <<interface>> 2nd 18 @ivanpaulovich • The dependencies point in the direction of the abstract components.
  15. Core Layer Infrastructure Layer Plugin Architecture OrderTicket ITicketRepository SQL Server

    / NoSQL <<interface>> 2nd Fake Storage 1st Development Order 19 @ivanpaulovich • The dependencies point in the direction of the abstract components. • The simplest component version are implemented first.
  16. Core Layer Infrastructure Layer Plugin Architecture OrderTicket ITicketRepository SQL Server

    / NoSQL Fake Storage Cloud Storage Development Order • The dependencies point in the direction of the abstract components. • The simplest component version are implemented first. • Defer decisions. Keep the options open as long as possible! <<interface>> 1st 2nd 3rd 20 @ivanpaulovich
  17. Use Cases Implementation Guided by Tests • Test Cases are

    the first consumers implemented. • Design the Use Cases with Single Responsibility Principle in mind. • Fake implementations are 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 21 @ivanpaulovich
  18. Use Cases Implementation Guided by Tests • Test Cases are

    the first consumers implemented. • Design the Use Cases with Single Responsibility Principle in mind. • Fake implementations are the first delivery mechanisms implemented. • Test Cases help you design fine grained Use Cases (Interface Segregation Principle). 22 @ivanpaulovich
  19. Whats is a Fake (Test Double)? • Runs in memory

    (No I/O). • Same capability as the real one. @ivanpaulovich
  20. 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 24 @ivanpaulovich
  21. Run the host 
 using Fakes Run the host 


    using the 
 Real Implementations @ivanpaulovich ASPNETCORE_ENVIRONMENT=Development ASPNETCORE_ENVIRONMENT=Production
  22. Application Infrastructure Unit Test Web Database Domain Ports and Adapters

    @ivanpaulovich 29 You can run it in Production if you want. Get feedback!
  23. Application Unit Test Web Database Domain Primary Actors Secondary Actors

    @ivanpaulovich 33 Infrastructure Ports and Adapters
  24. 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 Business Layer: 
 Reflection, Linq, Entity Framework, MVC, Data Annotations, WCF. 34 @ivanpaulovich
  25. The User Interface is a detail AccountsController IUseCase GetAccountDetails UseCase

    Core
 Layer User Interface
 Layer <<interface>> GetAccountDetails Input GetAccountDetails Presenter GetAccountDetails Output IOutputPort Response <<interface>> @ivanpaulovich 39
  26. Sample Application Ticket Terminal Todo List App Add Todo Item

    List Todo Items Do Undo User Storage 40 @ivanpaulovich
  27. Sample Application Ticket Terminal Todo List App Add Todo Item

    List Todo Items Do Undo User Storage 41 @ivanpaulovich
  28. 42 ✅ Commad-Line Task management with storage on your GitHub

    @ivanpaulovich $ dotnet tool install -g todo https://github.com/ivanpaulovich/todo
  29. Evolutionary Architecture In Action 43 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
  30. @ivanpaulovich Splitting packages on the software lifetime Domain Application Infrastructure

    User Interface Tests Tests Core Tests Core Infrastructure 1 2 3 4
  31. 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. 45 @ivanpaulovich
  32. References https://cleancoders.com Clean Code: Component Design Clean Code: SOLID Principles

    Clean Code: Fundamentals https://github.com/ivanpaulovich/clean-architecture-manga Robert C Martin - Clean Architecture and Design