Code decoupling from Symfony (and others frameworks) PHP Conf Asia 2018

1. Code decoupling from Symfony
(and others frameworks)
Miguel Gallardo
@mg3dem
PHP Conference Asia 2018

2. Who I am?
• Miguel Gallardo
• Traveling through Asia
• +15 years doing PHP and programming stuff
• Software Engineer @ ProPoint (http://
propointglobal.com/)
• @mg3dem - mgallardo@propointglobal.com

3. • Complicated legacy code
• Fragmented business logic
• Monolithic design
• Hard to test
• Technical debt!
• In house framework (Don’t reinvent the wheel!)
Why?

4. • New independent project
• Modern stack
• Strangler design pattern
Our approach

5. What’s next?

6. Decoupling?

7. –Wikipedia
“coupling is the degree of interdependence between
software modules; a measure of how closely
connected two routines or modules are; the strength
of the relationships between modules.”

8. Benefits of decoupling
• Minimize dependency of external frameworks, libraries
• Minimize backward compatibility breaks
• More portable
• More reusable
• Easier to change implementations
• Easier to maintain
• Easier to test
• More clean code and architecture

9. Symfony
(Our approach)

10. The framework isn’t a part of your application

11. View
Controller
Framework
Independent
Code
Data source

12. View
Controller
Service
Repository
Entity
Data source

13. Some rules

14. All code MUST obey the Law of Demeter
Each unit should only talk to its friends; don't talk to strangers.

15. All code MUST follow the Single Responsibility Principal
Each unit should have responsibility over a
single part of the functionality

16. Software entities should be
open for extension, but closed for modification

17. • Represents a single record of data
• Getters and Setters
• Can link to other entities that represent the relations
between them
• Must be independent of the hosting framework
Entity

19. • Represents the data persistence layer
• Should be lean and free from business logic.
• Interface
Repository

22. • Contains all of the business logic of an application
• Should be completely agnostic to data persistence.
• May use other services for data retrieval
• But NOT to persist data.
• Use event subscribers instead!
• Must be independent of the hosting framework
Service

24. • Focus on receiving an incoming HTTP request, fetching
incoming parameters and returning an HTTP response.
• Must be kept lean and free from business logic.
• Pass parameter to services for processing
• And use the results to generate a response.
Controller - View

26. The full picture

28. Don’t use decoupling
(everywhere)
it can be abused and its usefulness depends on the type of the project.

29. • Think of your modules as independent, as if the rest of
the program does not exist
• Prefer abstractions - they tend to help you think of your
modules as independent
• Design patterns of course
• Cohesive code is often decoupled
• Prefer composition, over inheritance
• Use layers of architecture

30. Thanks!
Miguel Gallardo
@mg3dem