Application architecture
0 likes154 views
The document discusses application architecture, emphasizing that frameworks like Symfony are tools rather than foundational architecture. It explores various business logic patterns, such as transaction scripts, table modules, and domain models, alongside their advantages and disadvantages. It also critiques antipatterns like the anemic domain model and highlights the distinctions between connected and modular systems in relation to feature interaction and costs.
Application architecture
- 2. Architecture, the lost years Robert C. Martin
- 3. “Web” is not an 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?
- 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?
- 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
- 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
- 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
- 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
- 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!