Slide 1

Slide 1 text

Clean Architecture Essentials Ivan Paulovich
 Stockholm Software Craftsmanship November 13, 2019 https://paulovich.net @ivanpaulovich

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Ivan Paulovich Agile Software Developer, Tech Lead, 20+ GitHub projects about Clean Architecture, SOLID, DDD and TDD. 
 Speaker/Streamer. @ivanpaulovich

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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!

Slide 6

Slide 6 text

Architecture is About Usage 6 @ivanpaulovich

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Business v Primary Actors @ivanpaulovich 9 Ports and Adapters Cloud Messaging UI In Memory Persistence Tests In Memory Messaging SQL Secondary Actors

Slide 10

Slide 10 text

Use Cases @ivanpaulovich

Slide 11

Slide 11 text

Abstractions and Stability Principles @ivanpaulovich Concrete
 Specific 
 Unstable Abstract 
 General
 Stable

Slide 12

Slide 12 text

@ivanpaulovich Abstract ⭐ ⭐ 
 General ⭐ ⭐
 Stable ⭐ ⭐ Concrete ⭐ ⭐ 
 Inconsistent ⭐ ⭐
 Specific ⭐ ⭐ Abstractions and Stability Principles Concrete ⭐ ⭐ 
 Consistent ⭐ 
 Specific ⭐

Slide 13

Slide 13 text

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.

Slide 14

Slide 14 text

Entities Use Cases Controllers Presenters Gateways Devices UI DB Web External Interfaces Abstract, General, 
 Stable, Consistent Concrete, Specific, 
 Unstable, Inconsistent Level Clean Architecture @ivanpaulovich

Slide 15

Slide 15 text

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 <> <> @ivanpaulovich

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Core Layer Infrastructure Layer Plugin Architecture OrderTicket ITicketRepository SQL Server / NoSQL <> 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.

Slide 20

Slide 20 text

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! <> 1st 2nd 3rd 20 @ivanpaulovich

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Whats is a Fake (Test Double)? • Runs in memory (No I/O). • Same capability as the real one. @ivanpaulovich

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Run the host 
 using Fakes Run the host 
 using the 
 Real Implementations @ivanpaulovich ASPNETCORE_ENVIRONMENT=Development ASPNETCORE_ENVIRONMENT=Production

Slide 26

Slide 26 text

Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich 26

Slide 27

Slide 27 text

Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich 27

Slide 28

Slide 28 text

Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich 28

Slide 29

Slide 29 text

Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich 29 You can run it in Production if you want. Get feedback!

Slide 30

Slide 30 text

Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich 30

Slide 31

Slide 31 text

Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich 31

Slide 32

Slide 32 text

Application Infrastructure Unit Test Web Database Domain Ports and Adapters @ivanpaulovich 32

Slide 33

Slide 33 text

Application Unit Test Web Database Domain Primary Actors Secondary Actors @ivanpaulovich 33 Infrastructure Ports and Adapters

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

• First-Class Collection. • Encapsulation.

Slide 36

Slide 36 text

The User Interface is a detail

Slide 37

Slide 37 text

The User Interface is a detail

Slide 38

Slide 38 text

The User Interface is a detail

Slide 39

Slide 39 text

The User Interface is a detail AccountsController IUseCase GetAccountDetails UseCase Core
 Layer User Interface
 Layer <> GetAccountDetails Input GetAccountDetails Presenter GetAccountDetails Output IOutputPort Response <> @ivanpaulovich 39

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

42 ✅ Commad-Line Task management with storage on your GitHub @ivanpaulovich $ dotnet tool install -g todo https://github.com/ivanpaulovich/todo

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

@ivanpaulovich Splitting packages on the software lifetime Domain Application Infrastructure User Interface Tests Tests Core Tests Core Infrastructure 1 2 3 4

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

47 Ask me two questions! @ivanpaulovich Fork me on GitHub