Slide 1

Slide 1 text

Ivan Paulovich @ivanpaulovich Stockholm, 2020 Nov 18th Clean Architecture

Slide 2

Slide 2 text

@ivanpaulovich

Slide 3

Slide 3 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 3 @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 Not a Software Architecture!

Slide 5

Slide 5 text

What is the Clean Architecture Style? @ivanpaulovich

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

@ivanpaulovich

Slide 8

Slide 8 text

Clean Architecture Style @ivanpaulovich Clean Architecture Style

Slide 9

Slide 9 text

Clean Architecture Style @ivanpaulovich Clean Architecture Style Hexagonal Architecture Style Clean Architecture Style @ivanpaulovich

Slide 10

Slide 10 text

Clean Architecture Style @ivanpaulovich Clean Architecture Style Hexagonal Architecture Style Ports and Adapters Pattern Dependency Inversion
 Principle Test-Driven Development Clean Architecture Style @ivanpaulovich

Slide 11

Slide 11 text

Clean Architecture Style Hexagonal Architecture Style Ports and Adapters Pattern Dependency Inversion
 Principle Test-Driven Development Clean Architecture Style Object-Oriented Design
 Principles Use Cases as Central Organising Structure Pluggable User Interface @ivanpaulovich

Slide 12

Slide 12 text

Hexagonal Architecture Style 1. Ports and Adapters pattern. 2. The implementation is guided by tests. 3. It is decoupled from technology details. @ivanpaulovich

Slide 13

Slide 13 text

Business @ivanpaulovich 13 Ports and Adapters Cloud 
 Messaging UI In Memory 
 Persistence 
 Tests In Memory 
 Messaging 
 SQL

Slide 14

Slide 14 text

Business @ivanpaulovich 14 Ports and Adapters Cloud 
 Messaging UI In Memory 
 Persistence 
 Tests In Memory 
 Messaging 
 SQL Ports

Slide 15

Slide 15 text

Ports @ivanpaulovich

Slide 16

Slide 16 text

Business v @ivanpaulovich 16 Ports and Adapters Cloud 
 Messaging UI In Memory 
 Persistence 
 Tests In Memory 
 Messaging 
 SQL Adapters

Slide 17

Slide 17 text

Adapters

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

A Web of Objects @ivanpaulovich

Slide 20

Slide 20 text

? ? ? Test Expectations @ivanpaulovich A Web of Objects

Slide 21

Slide 21 text

The First Test Deposit 
 Use Case Customer 
 Repository Account Repository Test Expectations @ivanpaulovich

Slide 22

Slide 22 text

The Walking Skeleton Deposit 
 Use Case Customer 
 Repository Account Repository Fakes User 
 Interface @ivanpaulovich

Slide 23

Slide 23 text

Deposit 
 Use Case Customer 
 Repository Account Repository Fakes User 
 Interface Integration Tests s Account Repository Test Customer 
 Repository

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Services Controllers Repositories Use Cases Domain Unit Tets Fake API Fake DB Unit Tests @ivanpaulovich

Slide 26

Slide 26 text

Services Controllers Repositories Use Cases Domain Component 
 Tests HTTP Component Tests @ivanpaulovich Fake API Fake DB

Slide 27

Slide 27 text

Services Controllers Repositories Use Cases Domain External APIS Database TCP HTTP Integration Tests Integration Tests @ivanpaulovich

Slide 28

Slide 28 text

Application External APIS Database End to End 
 Tests HTTP TCP HTTP End to End Tests @ivanpaulovich

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Controller Use Case Core User Interface @ivanpaulovich Request Response Input Output • Abstract • General • Stable • Consistent • Concrete • Speci f i c • Unstable • Inconsistent

Slide 31

Slide 31 text

Deposit Use Case @ivanpaulovich

Slide 32

Slide 32 text

Deposit Use Case Input and Output Messages @ivanpaulovich

Slide 33

Slide 33 text

Object-Oriented Design Principles

Slide 34

Slide 34 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. •Modules depend in the direction of stability. •Classes that change together are packaged together.

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

Takeaways • Clean Architecture is about usage and the use cases are the central organising structure. • Use cases implementation are guided by tests. • The User Interface and Persistence adapters are designed to ful f i l the core needs (not the opposite!). • Defer decisions by implementing the simplest component f i rst. 40 @ivanpaulovich

Slide 41

Slide 41 text

@ivanpaulovich