This document discusses principles of advanced web application architecture. It recommends separating applications into domain logic and infrastructure/framework-specific code by introducing layers. It also recommends defining ports and adapters using a hexagonal/ports and adapters architecture to increase testability and flexibility. This allows infrastructure/framework code to change without affecting domain logic ports, and makes it easier to keep up with changing frameworks. Sources provided discuss this architecture approach in more detail.

1. Advanced Web Application
Architecture
@matthiasnoback
info@matthiasnoback.nl
Slides are onTwitter
Questions via the website please :)

2. Somebody's wrong in the internet

3. I'm one of them

4. This is not to say that we shouldn't listen to any
advice!

5. Where does advice come from?

6. Experience
● You look back on a recent project that went well
● You look at your choices and consider them the
cause of the project's success
● You tell other people to make the same choices.

7. People will copy your choices

8. They fail

9. "They got it all wrong, just do this!"

10. Don't follow anyone

11. Listen to your code
Listen to its design

12. Collect and share heuristics

13. Heuristics?

14. What worked well
In which situation
And what's a good rule of thumb for it

15. Should you...
Call façades?
Use Yaml?
Write methods you can call with 0, 1 or 2 arguments?
Use middlewares?
Over-engineer your project using hexagonal architecture?

16. Write about what your experience

18. Change is really hard for most
software projects I've encountered

19. Reasons for change
Framework integration code

20. Reasons for change
Remote service calls

21. Reasons for change
Domain model

22. Single responsibility principle
for architecture
What changes for the same reason
should be grouped together

23. Examples
● All the things related to your framework
● All the things related to your domain model
● All the things related to your database
● ...

24. The most important distinction is...
Not too many groups

25. Domain vs Infrastructure
● Model
(entities, value objects)
● Use cases
(application services)
● Interfaces for boundary
objects
● Framework-specific code
● Implementations for
boundary objects
● Web controllers, CLI
controllers, etc.

26. Step 1
Introduce layers

27. Step 1: Introduce layers
Web framework
Domain logic
Database integration

28. Introduce layers
Web framework
Domain logic
Database integration
InfrastructureDomain

29. Step 2
Define ports and adapters
(Hexagonal architecture; Alistair Cockburn)

30. Determine actors
Application
Primary actor:
User
Secondary actor:
Database
Primary actor:
User
Secondary actor:
Remote
webservice
Primary actor:
Cronjob

31. Make a distinction...
Between the intention for communication,
and the supporting implementation

32. Examples
The user can buy a ticket

33. Examples
We have a TicketsController with a
buyTicket action. It gets the logged in user from
the session and gets the user's address from the
submitted form data.

34. Examples
We need to persist an order

35. Examples
We store order data in an orders table in our
MySQL database. We use Doctrine DBAL to talk
with that database.

36. Ports
Buyaticket
Persistanorder

37. Adapters
Buyaticket
Persistanorder
HTTPadapter
SQLadapter

38. Advantages
By separating domain from infrastructure code you
automatically increase testablity

39. Advantages
You can replace an adapter without
affecting the ports

40. Advantages
You can postpone the choice for
database vendor, framework, ORM, etc.

41. Advantages
You can more easily keep up with
the change rate of framework-specific code

42. Advantages
Or replace the framework altogether...

43. Sources
● Alistair in the "Hexagone": https://www.youtube.com/watch?v=th4AgBcrEHA
● My upcoming book "Advanced Web Application Architecture"
https://leanpub.com/web-application-architecture/
● Nat Pryce, Steve Freeman - Growing Object-Oriented Software, Guided by Tests
● Vaughn Vernon - Implementing Domain-Driven Design (see the chapter about
Architecture)

44. Q & A

45. Thank you!
@matthiasnoback
info@matthiasnoback.nl