About the talk: Software Architecture is not about picking frameworks then gluing the pieces together! Let's dig into a software implementation designed to support the use cases, we will learn how to make the use cases a standalone component and see how a good architecture allows major decisions to be deferred. We will discuss component coupling and cohesion during the development timeline. Is your application architecture a Web Application? Are your tests taking too long to run? You will learn how to make the delivery mechanism an irrelevant and testable detail. About the speaker: Ivan Paulovich is an Agile .NET developer that enjoy solutions based on use cases and decoupled from technology details. Active on GitHub he supports OSS about Domain-Driven Design, TDD, Event Sourcing, CQRS, SOLID and Microservices. Microsoft MVP Reconnect. Checkout @ivanpaulovich on GitHub.

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

2. 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

3. Ivan Paulovich
Agile Software Developer, Tech Lead,
20+ GitHub projects about Clean
Architecture, SOLID, DDD and TDD.
Speaker/Streamer.
@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
4 @ivanpaulovich

5. 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!

6. Architecture is About Usage
6 @ivanpaulovich

7. 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

8. 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

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

10. Use Cases
@ivanpaulovich

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

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

13. EntitiesEntities
CleanArchitecture
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.

14. Entities
Use Cases
Controllers
Presenters
Gateways
Devices UIDB Web
External Interfaces
Abstract, General,
Stable, Consistent
Concrete, Specific,
Unstable,
Inconsistent
Level
CleanArchitecture
@ivanpaulovich

15. 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

16. 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

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

18. 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.

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

20. 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

21. 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

22. 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

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

24. 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

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

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

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

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

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

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

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

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

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

34. 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

35. • First-Class Collection.
• Encapsulation.

36. The User Interface is a detail

37. The User Interface is a detail

38. The User Interface is a detail

39. 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>>
@ivanpaulovich39

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

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

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

43. 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

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

45. 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

46. 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

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