Software Architecture is not about picking frameworks and 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 API? Are your tests taking too long to run? You will learn how to make the delivery mechanism an irrelevant and testable detail.

1. Clean Architecture Essentials
Ivan Paulovich
Betsson Dev’Talk #4
Stockholm - 23rd May 2019
@ivanpaulovich https://paulovich.net

2. Ivan Paulovich
Software craftsman and GitHub addicted.
Interested in TDD, SOLID and
Clean Architecture.
@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
!3 @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
Not a Software
Architecture!

5. @ivanpaulovich!5
Resources I Like

6. Architecture is About Usage
!6 @ivanpaulovich

7. Architecture is About Usage
• The floor plan shows where people
enter the building and sit. It shows
where the focus is.
!7 @ivanpaulovich

8. Architecture is About Usage
• The floor plan shows where people
enter the building and sit. It shows
where the focus is.
• When looking at the image it is
easy to notice that it is a church
floor plan.
!8 @ivanpaulovich

9. Architecture is About Usage
• The floor plan shows where people
enter the building and sit. It shows
where the focus is.
• When looking at the image it is
easy to notice that it is a church
floor plan.
How to make the software
architecture scream its
usage?
!9 @ivanpaulovich

10. Use Cases
Ticket Terminal
Ticket Terminal
Display movies
Request
movie details
Print pre-ordered
tickets
Order tickets
Customer
Movie Catalog
Order System
Credit
Processing
!10 @ivanpaulovich

11. Use Cases
Ticket Terminal
Ticket Terminal
Display movies
Request
movie details
Print pre-ordered
tickets
Order tickets
Customer
Movie Catalog
Order System
Credit
Processing
• Use Cases are delivery independent,
they show the intent of a system.
!11 @ivanpaulovich

12. Use Cases
Ticket Terminal
Ticket Terminal
Display movies
Request
movie details
Print pre-ordered
tickets
Order tickets
Customer
Movie Catalog
Order System
Credit
Processing
• Use Cases are delivery independent,
they show the intent of a system.
• Use Cases are algorithms which
interpret the input to generate the
output data.
!12 @ivanpaulovich

13. 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,
they show the intent of a system.
• Use Cases are algorithms which
interpret the input to generate the
output data.
• Primary and secondary actors.
!13 @ivanpaulovich

14. Use Cases Implementation
Guided by Tests
• Test Cases should be the first consumers implemented. Test Cases
Use Cases
Core
Layer
Test Suite
!14 @ivanpaulovich

15. Use Cases Implementation
Guided by Tests
• Test Cases should be the first consumers implemented.
• You should design the Use Cases by following the
Single Responsibility Principle.
Test Cases
Use Cases
Core
Layer
Test Suite
!15 @ivanpaulovich

16. Use Cases Implementation
Guided by Tests
• Test Cases should be the first consumers implemented.
• You should design the Use Cases by following the
Single Responsibility Principle.
• Fake implementations should be the first delivery
mechanisms implemented.
Test Cases
Use Cases
Fake
Persistence
Core
Layer
Infrastructure
Layer
Test Suite
!16 @ivanpaulovich

17. Use Cases Implementation
Guided by Tests
• Test Cases should be the first consumers implemented.
• You should design the Use Cases by following the
Single Responsibility Principle.
• Fake implementations should be 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
!17 @ivanpaulovich

18. Software Architecture
“A good architecture allows major decisions
to be deferred. A good architect maximizes
the number of decisions not made.
Uncle Bob.
!18
@ivanpaulovich

19. Decoupling
User Interface, Use Cases and Repositories
TicketController IOrderTicketUseCase
OrderTicket ITicketRepository
SQLTicket
Storage
Core
Layer
Infrastructure
Layer
User Interface
Layer
Abstract,
General,
Stable
Concrete,
Specific,
Unstable
Concrete,
Specific,
Unstable
Level
Level
!19
<<interface>>
<<interface>>
@ivanpaulovich

20. Plugin Architecture
OrderTicket ITicketRepository
SQLTicket
Storage
<<interface>>
Core
Layer
Infrastructure
Layer !20 @ivanpaulovich
• The dependencies point in the direction of the abstract components.

21. Plugin Architecture
OrderTicket ITicketRepository
SQLTicket
Storage
<<interface>>
Core
Layer
Infrastructure
Layer
2nd
!21 @ivanpaulovich
• The dependencies point in the direction of the abstract components.

22. Plugin Architecture
OrderTicket ITicketRepository
SQLTicket
Storage
<<interface>>
Core
Layer
Infrastructure
Layer
2nd
InMemoryTicket
Storage
1st
Development Order!22 @ivanpaulovich
• The dependencies point in the direction of the abstract components.
• First implement the simplest component version!

23. Plugin Architecture
OrderTicket ITicketRepository
SQLTicket
StorageInMemoryTicket
Storage
OrderSystemTicket
Storage
Development Order
• The dependencies point in the direction of the abstract components.
• First implement the simplest component version!
• Defer decisions. Keep the options open as long as possible!
<<interface>>
Core
Layer
Infrastructure
Layer
1st
2nd 3rd
!23 @ivanpaulovich

24. High Level Design
SQL
Storage
Order
Service
MVC
In Memory
Storage
Main
Core
Layer
Infrastructure
Layer
User Interface
Layer
Console
@ivanpaulovich
• Complex systems should be made of components that are
designed, implemented and tested in isolation.

25. High Level Design
SQL
Storage
Order
Service
MVC
In Memory
Storage
Main
Core
Layer
Infrastructure
Layer
User Interface
Layer
Console
@ivanpaulovich
• Complex systems should be made of components that are
designed, implemented and tested in isolation.
• Some components share implementation symmetry.

26. Components Overview
1. Components are designed to fulfill the Core needs and
are implemented and tested in isolation.
Test Cases
Infrastructure
Layer
Test Suite
SQL
Storage
!26 @ivanpaulovich

27. 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.
Test Cases
Infrastructure
Layer
Test Suite
SQL
Storage
!27 @ivanpaulovich

28. 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
!28 @ivanpaulovich

29. Frameworks are Details
• Application code called by frameworks should be under control.
!29
@ivanpaulovich

30. Frameworks are Details
• Application code called by frameworks should be under control.
• Hide 3rd party libraries, use them behind core interfaces.
!30
@ivanpaulovich

31. 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.
!31
@ivanpaulovich

32. 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 application: Reflection, Linq, Entity Framework, MVC,
Data Annotations, WCF.
!32
@ivanpaulovich

33. The UI is a detail
TicketController IOrderTicketUseCase OrderTicket
Core
Layer
User Interface
Layer
<<interface>>
OrderTicket
Request
OrderTicketPresenter
OrderTicket
Response
IOrderResponseHandler
OrderTicket
Model
<<interface>>
@ivanpaulovich!33

34. Layered Diagram
Domain
Application
Infrastructure
User Interface
@ivanpaulovich!34

35. Application
Infrastructure
Unit Test
Web
Database
Domain
Ports and Adapters
@ivanpaulovich!35

36. Application
Infrastructure
Unit Test
Web
Database
Domain
Ports and Adapters
@ivanpaulovich!36

37. Application
Infrastructure
Unit Test
Web
Database
Domain
Ports and Adapters
@ivanpaulovich!37

38. Application
Infrastructure
Unit Test
Web
Database
Domain
Ports and Adapters
@ivanpaulovich!38

39. Application
Infrastructure
Unit Test
Web
Database
Domain
Ports and Adapters
@ivanpaulovich!39

40. Application
Infrastructure
Unit Test
Web
Database
Domain
Ports and Adapters
@ivanpaulovich!40

41. Application
Infrastructure
Unit Test
Web
Database
Domain
Ports and Adapters
@ivanpaulovich!41

42. Application
Unit Test
Web
Database
Domain
Primary
Actors
Secondary
Actors
@ivanpaulovich!42
Infrastructure
Ports and Adapters

43. Evolutionary Architecture Definition:
An evolutionary architecture supports
guided, incremental changes as a first
principle across multiple dimensions.
!43
@ivanpaulovich

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

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

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

47. Evolutionary Architecture In Action
!47
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

48. @ivanpaulovich
Packages on the software lifetime
Domain
Application
Infrastructure
User Interface
Tests
Tests
Core
Tests
Core
Infrastructure
1 2 3 4

49. Wrapping up Clean Architecture
• Clean Architecture is about usage and the use cases are the central
organising principle.
!49
@ivanpaulovich

50. 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.
!50
@ivanpaulovich

51. 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!).
!51
@ivanpaulovich

52. 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.
!52
@ivanpaulovich

53. Fork me on GitHub
!53
Ask me
2 Questions!
@ivanpaulovich