Download to read offline
Uploaded byIván Stepaniuk
Application architecture
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.
More Related Content
Similar to Application architecture
Application architecture
- 1.
- 2. Architecture, the lost years RobertC. Martin
- 3. “Web” is notan architecture.
- 4.
- 5. Symfony is atool, not architecture.
- 6. Application metaphor, thethree layers 1 32
- 7. WAIT! What does thiseven mean?
- 8. 1. Interact withthe user, both ways 1 32
- 9. 3. Interact withoutside world, other systems 1 32
- 10. 2. The codethat justifies the app existence 1 32
- 11. Are these layersequally important?
- 12. Do we buildthem the same way?
- 13. Do these changeat the same pace?
- 14. It is allabout CHANGE
- 15. OK How does businesslogic look like?
- 16.
- 17. Transaction Script Modeled asprocedures + Easiest to understand. + Obvious transaction boundaries. - Difficult to de-duplicate.
- 18. Table Module Modeled asobjects and Record Sets + No DB vs. OO impedance mismatch. - Model is database-centric. - Objects, but not really OO.
- 19. Domain Model Modeled afterthe 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 afterthe 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 shouldI use?
- 22. Which one shouldwe use? Efforttoenhance Complexity of the business logic
- 23. Which one shouldwe use? Efforttoenhance Complexity of the business logic 7.42
- 24. Which pattern doessymfony follow?
- 25.
- 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.
- 30. Table Driven DomainModel - 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 DomainModel - 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.
- 33.
- 36. Connected Domain Model Ina 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.
- 38. WAIT! OK, Active Recordis bad, but what about productivity?
- 39.
- 40. Symfony vs. OOP Isnot the debate here
- 41. Hexagonal Architecture or Portsand Adapters
- 42.
- 43.
- 44.
- 45.
- 46. Or layers again 132 Delivery Domain Infrastructure
- 47. Or layers again 132 Srv ValuesController Entity Manager Template Form Queue Upstream Service Entities Delivery Domain Infrastructure
- 48. Questions? Or come andask me later!