SlideShare a Scribd company logo
Advanced (Simple)
Web Application Architecture
Matthias Noback
@matthiasnoback
A little bit of controversy for you
What makes a framework "good"?
"I make a lot of money with it"
Faulty heuristic
A hard question:
"Is it good?"
Gets replaced by an easy question:
"Do people make money with it?"
Advanced web application architecture - Talk
"I learn design patterns from it"
"My framework uses semantic versioning"
"My framework is great for prototyping"
"I can go to conferences about my framework"
A framework is not something to identify with,
but something you use, and know how to use to
your advantage
Frameworks dictate the structure of your project
High-level structural
elements
● Models/entities
● Controllers
● Views/templates
● Migrations
● Configuration
Thin controllers, fat models
● "Only briefly visit your
controller, go to your model
as fast as you can."
● In practice: we build services,
lots of them, and large ones
too.
Advanced web application architecture - Talk
The effects of a framework-
driven architecture
Implicit use cases
➢ It's not even clear what the
domain is about
➢ Impossible to reuse the use
case with a different delivery
mechanism
The effects of a framework-
driven architecture
Implicit connections to actors
Application
Primary actor:
User
Secondary actor:
Database
The effects of a framework-
driven architecture
Coupling to the framework
➢ Framework-specific classes
and (magic) ways of doing
things are all over the code
base
Why bad?
Use cases are interrelated
(legacy spaghetti)
➢ Hard to change anything
➢ Hard to add something new
Why bad?
Domain logic is mixed with
infrastructure logic
➢ Hard to specify/test in isolation
➢ Hard to design the most useful
domain model
Why bad?
Code is tied to a specific
(version of a) framework
➢ Hard to upgrade the
framework
➢ Hard to switch frameworks
What do we want?
● The ability to focus on domain
logic without thinking about
storage, web services, web
requests, etc.
● The ability to switch to a
different database, framework,
message queue, filesystem, etc.
We need to make a split between:
Infrastructure and Domain logic
The intention and the implementation of
communication
First: what is domain
logic/infrastructure
1. Saving an uploaded file to a cloud file storage
2. Instantiating an entity by calling its constructor
3. Storing an entity in the database
4. Calculating the total amount for an invoice
5. Making sure that an order has at least one line
6. Publishing a domain event to a message queue
Heuristic
● Try describing what the
system does without
mentioning any technology.
● Split the implementation
along these lines.
Example: Fixer
We convert the invoice line and total
amounts of the invoice currency by
sending a GET request to Fixer's
/api/latest API endpoint, providing
the invoice currency as the base currency
and EUR as the target currency.
Advanced web application architecture - Talk
Applying the heuristic
"We need to convert the invoice
line and total amounts of the
invoice currency. In order to do
this, we need to find out the
current exchange rate between
the invoice currency and our
standard currency (EUR)."
ExchangeRateProvider
Applying the heuristic
"We do this by sending a GET
request to Fixer's /api/latest API
endpoint, providing the invoice
currency as the base currency and
EUR as the target currency. The
result will be a JSON string which we
decode. We'll return a Rate value
object based on the data we receive."
FixerExchangeRateProvider implements
ExchangeRateProvider
Domain logic versus Infrastructure
Domain logic versus
Infrastructure
● Entities
● Value objects
● Repository
interfaces
● Domain
services
● SQL query
● HTTP headers
● File
permissions
● MIME types
● JSON/XML
encoding
Split the code in two parts
● One part which shows what
you're trying to accomplish.
● Another part which fills in the
low-level details.
What about...
A web controller action?
1. In the controller, only take out the
necessary data from the Request.
2. Call a service that knows nothing about
the web.
What about...
Saving an entity to the database?
1. Recognize the need for persistence,
and define an interface for it (e.g. a
repository interface).
2. Provide an implementation that knows
how to talk to your particular database.
Application service
Repository interface
Web controller
calls
uses
Repository implementation
implements
So far
● We've separated domain logic
from infrastructure
● We can replace the
infrastructure "layer"; domain
logic is independent of it
● We can test a complete use
case scenarios without invoking
infrastructure code
Application service
Repository interface
Test driver
calls
uses
Repository stub
implements
Application service
Repository interface
calls
uses
implements
W
ebcontroller
Testdriver
MySQL
Stub
calls
implements
Hexagonal architecture, or:
Ports & adapters
Port: an intention of a dialog
Adapter: supporting implementation for
the dialog
Hexagon: the application without its
adapters
Hexagonal architecture, or:
Ports & adapters
Port: "For saving entities" (represented by
a repository interface with a save()
method)
Adapter: "Save entities by sending SQL
insert/update statements to a MySQL
database" (implemented in a repository
class).
Application service
Repository interface
calls
uses
implements
W
ebcontroller
Testdriver
MySQL
Stub
calls
implements
Userinterface
Persistence
Notifications
Batchimport
News feed
Blob storage
Advanced web application architecture - Talk
Stub
MySQL
NoSQL
W
ebcontroller
CLIcommand
What does this bring us?
Domain logic is decoupled from
infrastructure, meaning that:
What does this bring us?
The domain logic can survive
the replacement of port adapters
What does this bring us?
We can create new adapters
for existing ports and swap them
What does this bring us?
We can switch frameworks
But, I'll never switch
frameworks...
You will
But, I'll never switch
frameworks...
Even a minor framework (or library)
upgrade can sometimes feel like a
complete switch
But, I'll never switch
frameworks...
Your favorite framework today will stop
being maintained some day (just like the
earth itself)
But, I'll never switch
frameworks...
What's modern and cool now, won't be in
just two years
What does this bring us?
We can test every part in isolation
(domain logic, adapters)
But, I don't write tests...
You have to
Why do developers not
write tests?
Because it involves a learning process on
top of the process of learning to write
code.
Why do developers not
write tests?
Because it seems to be possible to skip
the extra effort needed to write tests and
do something easier: write production
code.
Why do developers not
write tests?
The feedback loop is very big: you'll only
learn later that having a test suite is
absolutely required to keep the software
in a presentable state in the long run.
So please write your tests
Start learning today;
Reduce the extra effort it takes
And finally: enjoy the increase
in development speed
"What if my project is short-lived?"
The advice doesn't apply
(But don't decide to quickly)
What's a good framework?
A framework that doesn't get in the way
A good framework allows me to split:
Infrastructure and Domain logic
The intention and the implementation of
communication
Questions?
Matthias Noback
Training & Consultancy
matthiasnoback.nl

More Related Content

PDF
Advanced web application architecture Way2Web
PDF
Building Autonomous Services
PDF
Advanced web application architecture - PHP Barcelona
PDF
A testing strategy for hexagonal applications
PDF
Service abstractions - Part 1: Queries
PDF
Hexagonal Symfony - SymfonyCon Amsterdam 2019
PDF
Layers, ports and adapters
PDF
Brutal refactoring, lying code, the Churn, and other emotional stories from L...
Advanced web application architecture Way2Web
Building Autonomous Services
Advanced web application architecture - PHP Barcelona
A testing strategy for hexagonal applications
Service abstractions - Part 1: Queries
Hexagonal Symfony - SymfonyCon Amsterdam 2019
Layers, ports and adapters
Brutal refactoring, lying code, the Churn, and other emotional stories from L...

What's hot (20)

PDF
ITI006En-AJAX
PDF
Microservices with spring boot
PDF
Interop 2015: Hardly Enough Theory, Barley Enough Code
PDF
Reactive programming - Observable
PDF
Reactive programming and RxJS
PPTX
Reactive programming
PDF
Messaging
PPTX
Grokking TechTalk #16: Html js and three way binding
PPTX
Functional reactive programming
PDF
Services, dependencies, and you
PDF
Prometheus Introduction (InfraCoders Vienna)
PPT
Building Reactive webapp with React/Flux
PDF
Microservices - Please, don't
PPT
Ruby on rails intro
PPTX
Net developer days presentation
PDF
Test Driven Development
PDF
Gatling Performance Workshop
PPTX
Salesforce Apex Ten Commandments
PPTX
Sandro Mancuso – Testing and refactoring legacy code @ I T.A.K.E. Unconferenc...
ITI006En-AJAX
Microservices with spring boot
Interop 2015: Hardly Enough Theory, Barley Enough Code
Reactive programming - Observable
Reactive programming and RxJS
Reactive programming
Messaging
Grokking TechTalk #16: Html js and three way binding
Functional reactive programming
Services, dependencies, and you
Prometheus Introduction (InfraCoders Vienna)
Building Reactive webapp with React/Flux
Microservices - Please, don't
Ruby on rails intro
Net developer days presentation
Test Driven Development
Gatling Performance Workshop
Salesforce Apex Ten Commandments
Sandro Mancuso – Testing and refactoring legacy code @ I T.A.K.E. Unconferenc...
Ad

Similar to Advanced web application architecture - Talk (20)

PDF
Viktor Turskyi "Effective NodeJS Application Development"
PPT
Struts 2-overview2
PDF
The working architecture of NodeJS applications, Виктор Турский
PDF
The working architecture of node js applications open tech week javascript ...
PPTX
Over view of software artitecture
PPTX
ReactJS - Re-rendering pages in the age of the mutable DOM
PDF
Open shift and docker - october,2014
PDF
Workshop: Delivering chnages for applications and databases
PDF
Code for Startup MVP (Ruby on Rails) Session 1
PPTX
What's New in .Net 4.5
PPTX
O365 Developer Bootcamp NJ 2018 - Material
PDF
PDF
'Effective node.js development' by Viktor Turskyi at OdessaJS'2020
PPTX
L06 Using Design Patterns
PDF
Andrii Sliusar "Module Architecture of React-Redux Applications"
PDF
Web Component Development Using Servlet & JSP Technologies (EE6) - Chapter 1...
PPTX
Advanced Web Technology using Django.pptx
PDF
Elements for an iOS Backend
PDF
Sharing our best secrets: Design a distributed system from scratch
PPT
Praxistaugliche notes strategien 4 cloud
Viktor Turskyi "Effective NodeJS Application Development"
Struts 2-overview2
The working architecture of NodeJS applications, Виктор Турский
The working architecture of node js applications open tech week javascript ...
Over view of software artitecture
ReactJS - Re-rendering pages in the age of the mutable DOM
Open shift and docker - october,2014
Workshop: Delivering chnages for applications and databases
Code for Startup MVP (Ruby on Rails) Session 1
What's New in .Net 4.5
O365 Developer Bootcamp NJ 2018 - Material
'Effective node.js development' by Viktor Turskyi at OdessaJS'2020
L06 Using Design Patterns
Andrii Sliusar "Module Architecture of React-Redux Applications"
Web Component Development Using Servlet & JSP Technologies (EE6) - Chapter 1...
Advanced Web Technology using Django.pptx
Elements for an iOS Backend
Sharing our best secrets: Design a distributed system from scratch
Praxistaugliche notes strategien 4 cloud
Ad

More from Matthias Noback (20)

PDF
Rector fireside chat - PHPMiNDS meetup
PDF
DPC 2019, Amsterdam: Beyond design patterns and principles - writing good OO ...
PDF
Beyond design principles and patterns (muCon 2019 edition)
PDF
Brutal refactoring, lying code, the Churn, and other emotional stories from L...
PDF
Beyond Design Principles and Patterns
PDF
Advanced Application Architecture Symfony Live Berlin 2018
PDF
Designing for Autonomy
PDF
Docker workshop
PDF
Docker swarm workshop
PDF
Docker compose workshop
PDF
Building autonomous services
PDF
Designing for autonomy
PDF
Advanced application architecture
PDF
Continously delivering containerized microservices
PDF
Apprendre le français
PDF
Living Documentation (presentation)
PDF
TDD - A Reminder of the Principles
PDF
Docker workshop
PDF
CQRS & Event Sourcing
PDF
Advanced Application Architecture (workshop slides)
Rector fireside chat - PHPMiNDS meetup
DPC 2019, Amsterdam: Beyond design patterns and principles - writing good OO ...
Beyond design principles and patterns (muCon 2019 edition)
Brutal refactoring, lying code, the Churn, and other emotional stories from L...
Beyond Design Principles and Patterns
Advanced Application Architecture Symfony Live Berlin 2018
Designing for Autonomy
Docker workshop
Docker swarm workshop
Docker compose workshop
Building autonomous services
Designing for autonomy
Advanced application architecture
Continously delivering containerized microservices
Apprendre le français
Living Documentation (presentation)
TDD - A Reminder of the Principles
Docker workshop
CQRS & Event Sourcing
Advanced Application Architecture (workshop slides)

Recently uploaded (20)

PPTX
Essential Infomation Tech presentation.pptx
PPTX
Materi_Pemrograman_Komputer-Looping.pptx
PPTX
Odoo POS Development Services by CandidRoot Solutions
PDF
How to Migrate SBCGlobal Email to Yahoo Easily
PDF
medical staffing services at VALiNTRY
PPTX
CHAPTER 12 - CYBER SECURITY AND FUTURE SKILLS (1) (1).pptx
PDF
Flood Susceptibility Mapping Using Image-Based 2D-CNN Deep Learnin. Overview ...
PDF
How Creative Agencies Leverage Project Management Software.pdf
PPTX
VVF-Customer-Presentation2025-Ver1.9.pptx
PDF
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
PPT
JAVA ppt tutorial basics to learn java programming
PDF
Upgrade and Innovation Strategies for SAP ERP Customers
PDF
Design an Analysis of Algorithms II-SECS-1021-03
PDF
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
PPTX
ISO 45001 Occupational Health and Safety Management System
PDF
Wondershare Filmora 15 Crack With Activation Key [2025
PDF
Softaken Excel to vCard Converter Software.pdf
PDF
Which alternative to Crystal Reports is best for small or large businesses.pdf
PDF
Adobe Premiere Pro 2025 (v24.5.0.057) Crack free
PDF
AI in Product Development-omnex systems
Essential Infomation Tech presentation.pptx
Materi_Pemrograman_Komputer-Looping.pptx
Odoo POS Development Services by CandidRoot Solutions
How to Migrate SBCGlobal Email to Yahoo Easily
medical staffing services at VALiNTRY
CHAPTER 12 - CYBER SECURITY AND FUTURE SKILLS (1) (1).pptx
Flood Susceptibility Mapping Using Image-Based 2D-CNN Deep Learnin. Overview ...
How Creative Agencies Leverage Project Management Software.pdf
VVF-Customer-Presentation2025-Ver1.9.pptx
Addressing The Cult of Project Management Tools-Why Disconnected Work is Hold...
JAVA ppt tutorial basics to learn java programming
Upgrade and Innovation Strategies for SAP ERP Customers
Design an Analysis of Algorithms II-SECS-1021-03
Why TechBuilder is the Future of Pickup and Delivery App Development (1).pdf
ISO 45001 Occupational Health and Safety Management System
Wondershare Filmora 15 Crack With Activation Key [2025
Softaken Excel to vCard Converter Software.pdf
Which alternative to Crystal Reports is best for small or large businesses.pdf
Adobe Premiere Pro 2025 (v24.5.0.057) Crack free
AI in Product Development-omnex systems

Advanced web application architecture - Talk

  • 1. Advanced (Simple) Web Application Architecture Matthias Noback @matthiasnoback
  • 2. A little bit of controversy for you What makes a framework "good"?
  • 3. "I make a lot of money with it"
  • 4. Faulty heuristic A hard question: "Is it good?" Gets replaced by an easy question: "Do people make money with it?"
  • 6. "I learn design patterns from it"
  • 7. "My framework uses semantic versioning"
  • 8. "My framework is great for prototyping"
  • 9. "I can go to conferences about my framework"
  • 10. A framework is not something to identify with, but something you use, and know how to use to your advantage
  • 11. Frameworks dictate the structure of your project
  • 12. High-level structural elements ● Models/entities ● Controllers ● Views/templates ● Migrations ● Configuration
  • 13. Thin controllers, fat models ● "Only briefly visit your controller, go to your model as fast as you can." ● In practice: we build services, lots of them, and large ones too.
  • 15. The effects of a framework- driven architecture Implicit use cases ➢ It's not even clear what the domain is about ➢ Impossible to reuse the use case with a different delivery mechanism
  • 16. The effects of a framework- driven architecture Implicit connections to actors Application Primary actor: User Secondary actor: Database
  • 17. The effects of a framework- driven architecture Coupling to the framework ➢ Framework-specific classes and (magic) ways of doing things are all over the code base
  • 18. Why bad? Use cases are interrelated (legacy spaghetti) ➢ Hard to change anything ➢ Hard to add something new
  • 19. Why bad? Domain logic is mixed with infrastructure logic ➢ Hard to specify/test in isolation ➢ Hard to design the most useful domain model
  • 20. Why bad? Code is tied to a specific (version of a) framework ➢ Hard to upgrade the framework ➢ Hard to switch frameworks
  • 21. What do we want? ● The ability to focus on domain logic without thinking about storage, web services, web requests, etc. ● The ability to switch to a different database, framework, message queue, filesystem, etc.
  • 22. We need to make a split between: Infrastructure and Domain logic The intention and the implementation of communication
  • 23. First: what is domain logic/infrastructure 1. Saving an uploaded file to a cloud file storage 2. Instantiating an entity by calling its constructor 3. Storing an entity in the database 4. Calculating the total amount for an invoice 5. Making sure that an order has at least one line 6. Publishing a domain event to a message queue
  • 24. Heuristic ● Try describing what the system does without mentioning any technology. ● Split the implementation along these lines.
  • 25. Example: Fixer We convert the invoice line and total amounts of the invoice currency by sending a GET request to Fixer's /api/latest API endpoint, providing the invoice currency as the base currency and EUR as the target currency.
  • 27. Applying the heuristic "We need to convert the invoice line and total amounts of the invoice currency. In order to do this, we need to find out the current exchange rate between the invoice currency and our standard currency (EUR)." ExchangeRateProvider
  • 28. Applying the heuristic "We do this by sending a GET request to Fixer's /api/latest API endpoint, providing the invoice currency as the base currency and EUR as the target currency. The result will be a JSON string which we decode. We'll return a Rate value object based on the data we receive." FixerExchangeRateProvider implements ExchangeRateProvider
  • 29. Domain logic versus Infrastructure
  • 30. Domain logic versus Infrastructure ● Entities ● Value objects ● Repository interfaces ● Domain services ● SQL query ● HTTP headers ● File permissions ● MIME types ● JSON/XML encoding
  • 31. Split the code in two parts ● One part which shows what you're trying to accomplish. ● Another part which fills in the low-level details.
  • 32. What about... A web controller action? 1. In the controller, only take out the necessary data from the Request. 2. Call a service that knows nothing about the web.
  • 33. What about... Saving an entity to the database? 1. Recognize the need for persistence, and define an interface for it (e.g. a repository interface). 2. Provide an implementation that knows how to talk to your particular database.
  • 34. Application service Repository interface Web controller calls uses Repository implementation implements
  • 35. So far ● We've separated domain logic from infrastructure ● We can replace the infrastructure "layer"; domain logic is independent of it ● We can test a complete use case scenarios without invoking infrastructure code
  • 36. Application service Repository interface Test driver calls uses Repository stub implements
  • 38. Hexagonal architecture, or: Ports & adapters Port: an intention of a dialog Adapter: supporting implementation for the dialog Hexagon: the application without its adapters
  • 39. Hexagonal architecture, or: Ports & adapters Port: "For saving entities" (represented by a repository interface with a save() method) Adapter: "Save entities by sending SQL insert/update statements to a MySQL database" (implemented in a repository class).
  • 45. What does this bring us? Domain logic is decoupled from infrastructure, meaning that:
  • 46. What does this bring us? The domain logic can survive the replacement of port adapters
  • 47. What does this bring us? We can create new adapters for existing ports and swap them
  • 48. What does this bring us? We can switch frameworks
  • 49. But, I'll never switch frameworks... You will
  • 50. But, I'll never switch frameworks... Even a minor framework (or library) upgrade can sometimes feel like a complete switch
  • 51. But, I'll never switch frameworks... Your favorite framework today will stop being maintained some day (just like the earth itself)
  • 52. But, I'll never switch frameworks... What's modern and cool now, won't be in just two years
  • 53. What does this bring us? We can test every part in isolation (domain logic, adapters)
  • 54. But, I don't write tests... You have to
  • 55. Why do developers not write tests? Because it involves a learning process on top of the process of learning to write code.
  • 56. Why do developers not write tests? Because it seems to be possible to skip the extra effort needed to write tests and do something easier: write production code.
  • 57. Why do developers not write tests? The feedback loop is very big: you'll only learn later that having a test suite is absolutely required to keep the software in a presentable state in the long run.
  • 58. So please write your tests Start learning today; Reduce the extra effort it takes And finally: enjoy the increase in development speed
  • 59. "What if my project is short-lived?"
  • 60. The advice doesn't apply (But don't decide to quickly)
  • 61. What's a good framework? A framework that doesn't get in the way
  • 62. A good framework allows me to split: Infrastructure and Domain logic The intention and the implementation of communication
  • 63. Questions? Matthias Noback Training & Consultancy matthiasnoback.nl