Application Architecture Patterns talk tailored for PHP / Symfony developers. (2016). We describe the traditional layers, a Domain Model, Hexagonal architecture and how the pieces fit together.

1. Application Architecture
Iván Stepaniuk
@istepaniuk

2. Architecture,
the lost years
Robert C. Martin

3. “Web” is not an
architecture.

4. Frameworks are
not architecture.

5. Symfony is a tool,
not architecture.

6. Application metaphor, the three layers
1 32

7. WAIT!
What does this even mean?

8. 1. Interact with the user, both ways
1 32

9. 3. Interact with outside world, other systems
1 32

10. 2. The code that justifies the app existence
1 32

11. Are these layers equally important?

12. Do we build them the same way?

13. Do these change at the same pace?

14. It is all about
CHANGE

15. OK
How does business logic look like?

16. Patterns
Enterprise
Application
Architecture
Martin Fowler

17. Transaction Script
Modeled as procedures
+ Easiest to understand.
+ Obvious transaction boundaries.
- Difficult to de-duplicate.

18. Table Module
Modeled as objects and Record Sets
+ No DB vs. OO impedance mismatch.
- Model is database-centric.
- Objects, but not really OO.

19. Domain Model
Modeled after the business you work with.
+ Real OOP, with all the OO advantages.
- Hard to switch to if used to think data.
- Code overhead for simple logic.

20. Domain Model
Modeled after the business you work with.
+ Real OOP, with all the OO advantages.
- Hard to switch to if used to think data.
- Code overhead for simple logic.

21. Which pattern should I use?

22. Which one should we use?
Efforttoenhance
Complexity of the business logic

23. Which one should we use?
Efforttoenhance
Complexity of the business logic
7.42

24. Which pattern does symfony follow?

25. Domain Model
Architecture
Antipatterns

26. Anemic Domain Model
- Objects have state, but no behavior
- The Business is somewhere else
Leads to:
- Upside down Transaction Script
- God objects

27. Anemic Domain Model
- Objects have state, but no behavior
- The Business is somewhere else
Leads to:
- Upside down Transaction Script
- God objects

28. Inheritance!
To extend behaviour

30. Table Driven Domain Model
- The data model is the domain model
- All objects backed up by a table
Leads to:
- High viscosity
- Complex, slow, fragile tests
- CRUD obsession

31. Table Driven Domain Model
- The data model is the domain model
- All objects backed up by a table
Leads to:
- High viscosity
- Complex, slow, fragile tests
- CRUD obsession

32. CREATE
READ
UPDATE
DELETE

33. DATABASE
DATABASE
DATABASE
DATABASE

36. Connected Domain Model
In a connected system, elements are highly available to each other.
Adding the first feature to a connected system is cheap …
… the cost of all those connections is that subsequent features
are very likely to interact with previous features, driving up the the cost …
In a modular design, connections are deliberately kept to a minimum.
The cost of the first feature is likely to be higher …
Features are less likely to interact in a modular system, though,
leading to a steady stream of features at relatively constant cost.
- Kent Beck

37. Connected Domain Model

38. WAIT!
OK, Active Record is bad, but
what about productivity?

39. Symfony vs. OOP

40. Symfony vs. OOP
Is not the debate here

41. Hexagonal Architecture
or Ports and Adapters

42. Domain boundaries
Entities Services
Values
Integration

43. Domain boundaries
Entities Services
Values
Integration

44. Hexagon
Entities
Services
Values

45. Hexagon
Entities
Services
Values
Controller
Entity
Manager
Mail system
Template
Form
Queue
Upstream
Service

46. Or layers again
1 32
Delivery Domain Infrastructure

47. Or layers again
1 32 Srv
ValuesController
Entity
Manager
Template
Form Queue
Upstream
Service
Entities
Delivery Domain Infrastructure

48. Questions?
Or come and ask me later!