Hexagonal Architecture Style
Hexagonal Architecture Style
Principles Dependency Inversion Principle
Patterns Ports and Adapters Pattern
Practices Test-Driven Development
@ivanpaulovich
Slide 5
Slide 5 text
Dependency Inversion Principle
• High-level modules should not depend on low-level modules.
• Both should depend on abstractions.
• Abstractions should not depend on details.
• Details should depend on abstractions.
@ivanpaulovich
Slide 6
Slide 6 text
Ports and Adapters Pattern
Core
Cloud
E-mail
Noti
fi
cation
In Memory
Messaging
Database
In Memory
Persistence
MS SQL
Persistence
Web App
Unit Tests
User Interface
@ivanpaulovich
Noti
fi
cation
Slide 7
Slide 7 text
Ports
• Ports are the interfaces exposed by the application.
• Ports are highly abstract.
• Examples of ports are:
• Use Cases signatures;
• Required dependencies.
@ivanpaulovich
Slide 8
Slide 8 text
Ports
@ivanpaulovich
Slide 9
Slide 9 text
• Adapters implement Ports.
• Adapters are highly concrete.
• Adapters are very speci
fi
c.
• Adapters could be a Primary or Secondary Actors.
Adapters
@ivanpaulovich
Slide 10
Slide 10 text
• Examples of Adapters are:
• Web App Layer;
• Unit Tests;
• Data access implementations;
• Infrastructure components.
Adapters
@ivanpaulovich
Slide 11
Slide 11 text
Adapters
@ivanpaulovich
Slide 12
Slide 12 text
Application
Unit Test
Web
Database
Domain
Primary
Actors
Secondary
Actors
@ivanpaulovich
12
Infrastructure
Ports and Adapters
Slide 13
Slide 13 text
@ivanpaulovich
What’s TDD?
A practice to use tests to guide the software implementation.
Boosts the con
fi
dence to change and to deploy software.
Works as a team communication technique.
Slide 14
Slide 14 text
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
@ivanpaulovich
The Rules of TDD
1. You are not allowed to write any production code unless it is to make a failing
unit test pass.
2. You are not allowed to write any more of a unit test than is suf
fi
cient to fail;
and compilation failures are failures.
3. You are not allowed to write any more production code than is suf
fi
cient to
pass the one failing unit test.
Slide 15
Slide 15 text
Red-Green-Refactor
Red
Gren
Refactor
Write just enough code to
pass the test
Improve the code without
changing its behaviour
Write a test and
watch it fail
TDD Cycle
@ivanpaulovich
Slide 16
Slide 16 text
A Web of Objects
@ivanpaulovich
Slide 17
Slide 17 text
?
?
?
Test
Expectations
@ivanpaulovich
Design for Testing
Slide 18
Slide 18 text
The First Test
Deposit
Use Case
Customer
Repository
Account
Repository
Test
Expectations
@ivanpaulovich
Slide 19
Slide 19 text
The Walking Skeleton
Deposit
Use Case
Customer
Repository
Account
Repository
Fakes
User
Interface
@ivanpaulovich
Slide 20
Slide 20 text
Deposit
Use Case
Customer
Repository
Account
Repository
Fakes
User
Interface
Integration Tests
s
Account
Repository
Test
Customer
Repository
SQL Component
@ivanpaulovich
Slide 21
Slide 21 text
Hexagonal vs. Clean Architecture Style
Hexagonal Architecture Style
Principles Dependency Inversion Principle
Patterns Ports and Adapters Pattern
Practices Test-Driven Development
@ivanpaulovich
Slide 22
Slide 22 text
Hexagonal Architecture Style
Clean Architecture Style
Also Requires
Principles Dependency Inversion Principle
Stable Dependencies Principle;
Stable Abstractions Principle.
Patterns Ports and Adapters Pattern
Use Cases as central organising structure;
Pluggable user interface.
Practices Test-Driven Development
Hexagonal vs. Clean Architecture Style
@ivanpaulovich
Slide 23
Slide 23 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 24
Slide 24 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.
Principles
Slide 25
Slide 25 text
Entities
Use Cases
Controllers
Presenters
Gateways
Devices UI
DB Web
External Interfaces
Abstract,
General,
Stable,
Consistent
Concrete,
Speci
fi
c,
Unstable,
Inconsistent
Level
Clean Architecture
@ivanpaulovich
Slide 26
Slide 26 text
No content
Slide 27
Slide 27 text
No content
Slide 28
Slide 28 text
No content
Slide 29
Slide 29 text
No content
Slide 30
Slide 30 text
Use Case
• It is an application entry point.
• Shows the usage.
@ivanpaulovich
Slide 31
Slide 31 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.
31 @ivanpaulovich
Slide 32
Slide 32 text
Controller
Use Case
Core
User Interface
@ivanpaulovich
Request
Response
Input
Output
• Abstract
• General
• Stable
• Consistent
• Concrete
• Speci
fi
c
• Unstable
• Inconsistent
Slide 33
Slide 33 text
Deposit Use Case
@ivanpaulovich
Slide 34
Slide 34 text
Pluggable User Interface
• Your Core abstractions should support be the same even if your application
runs on a Web server or in a Console Terminal.
• Ideally your User Interface is a plugin to your application.
• The Core abstractions de
fi
ne expectations on what the UI should look like.
@ivanpaulovich
Slide 35
Slide 35 text
The “Presenter” Approach @ivanpaulovich
Slide 36
Slide 36 text
The “Presenter” Approach @ivanpaulovich
Slide 37
Slide 37 text
The “Presenter” Approach @ivanpaulovich
Slide 38
Slide 38 text
Testing Strategies
@ivanpaulovich
Slide 39
Slide 39 text
Services
Controllers
Repositories
Use Cases
Domain
External
APIS
Database
Single Page
Application
HTTP
TCP
HTTP
The
Typical Software Structure
@ivanpaulovich
Slide 40
Slide 40 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 41
Slide 41 text
Services
Controllers
Repositories
Use Cases
Domain
Unit Tests
Fake API
Fake DB
Unit Tests
@ivanpaulovich
Slide 42
Slide 42 text
@ivanpaulovich
Slide 43
Slide 43 text
Services
Controllers
Repositories
Use Cases
Domain
Component
Tests
HTTP
Component Tests
@ivanpaulovich
Fake API
Fake DB
Application
External
APIS
Database
End to End
Tests
HTTP
TCP
HTTP
End to End Tests
@ivanpaulovich
Slide 49
Slide 49 text
@ivanpaulovich
Slide 50
Slide 50 text
@ivanpaulovich
Slide 51
Slide 51 text
What kind of test should I write first?
Test Kind Criteria
Unit Tests
When use cases are complex and requires
learning.
Integration Tests
When integration protocols are critical and
complex.
Component Tests
When API Contracts need to be designed then
shared.
End To End Tests “Never”.
@ivanpaulovich
Slide 52
Slide 52 text
Tests Writing Considerations
Think about assertion. It should be short.
Each test has a single “System Under Test”.
Mocks are less valuable than fakes since only fakes could run in production.
@ivanpaulovich
Slide 53
Slide 53 text
Common Misconceptions
Test-First does not mean “Write the complete test then write the code.”
Test-First means “Write a little bit of the test then write a piece of the
production code.”
@ivanpaulovich
Slide 54
Slide 54 text
Clean Architecture Pitfalls.
When it starts to break.
@ivanpaulovich
Slide 55
Slide 55 text
Hard to scale out
• It takes time for a squad to learn the overall structure.
• It takes time for a squad to learn how to decouple from frameworks.
• It takes time to write better tests without Moq.
• It worked for me to have a “Unicorn” project that we could get inspired by.
@ivanpaulovich
Slide 56
Slide 56 text
Too much boilerplate
• We do write boilerplate around public interfaces.
• We do write boilerplate around implementing fakes components.
• We do write boilerplate around validation and common frameworks.
@ivanpaulovich
Slide 57
Slide 57 text
Boilerplate vs Frameworks
• Larger “Clean Architecture” implementations tend to have lots of boilerplate.
• At this advanced level a developer starts thinking about building a
“framework” to reduce it. He might consider:
1. Design the framework as part of the existing application.
2. Use frameworks and libraries of the shelf.
3. Or a mix of both.
@ivanpaulovich
Slide 58
Slide 58 text
Where to put exception handling?
• Exception handling should be implemented on adapters.
• Focus on exception handling on I/O.
@ivanpaulovich
Slide 59
Slide 59 text
Validation
• Validation without frameworks are painful to maintain.
• FluentValidation is very helpful.
• FluentValidation can be used following the Ports and Adapters pattern.
@ivanpaulovich
Slide 60
Slide 60 text
It is not Clean Architecture
when…
@ivanpaulovich
Slide 61
Slide 61 text
@ivanpaulovich
https://github.com/ivanpaulovich/clean-architecture-manga
Further references: