This document discusses hexagonal architecture with Symfony. It recommends separating domain logic from infrastructure code like frameworks to increase testability and allow replacing parts independently. It describes defining ports and adapters, with ports representing intentions to communicate and adapters providing implementations. For example, a "buy a ticket" port could be implemented by a HTTP adapter using a controller. The document argues this approach makes code easier to change and maintain while keeping up with framework updates.

1. Hexagonal Architecture
with Symfony
@matthiasnoback
info@matthiasnoback.nl
Slides are onTwitter

2. Somebody's wrong on the internet

12. Somebody's wrong on the internet

13. I'm one of them

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

15. Where does advice come from?

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

17. People will copy your choices

18. They fail

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

20. Don't follow anyone

21. Listen to your code
Listen to its design
Easy to move?
Easy to test?
Easy to add a
constructor
argument?
Easy to
rename?

22. Collect and share heuristics

23. Heuristics?

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

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

26. Write about what your experience

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

29. Reasons for change
Framework integration code

30. Reasons for change
Remote service calls

31. Reasons for change
Domain model

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

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

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

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

36. Step 1
Introduce layers

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

38. Introduce layers
Web framework
Domain logic
Database integration
InfrastructureDomain

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

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

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

42. Examples
The user can buy a ticket

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

44. Examples
We need to persist an order

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

46. Ports
Buyaticket
Persistanorder

47. Adapters
Buyaticket
Persistanorder
HTTPadapter
SQLadapter

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

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

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

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

52. Advantages
Or replace the framework altogether...

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

54. Questions?

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