Framework-Agnostic Applications - A story about components

In this talk, I covered some software architecture concepts in order to make more scalable and reusable application code avoiding coupling with framework tools.

Presented at PHP Experience 2018

Transcript

1. Framework-agnostic Applications A story about components Lucas Mendes 
 Software Architect at Tienda Nube Find me on Twitter: @devsdmf
2. $ whoami
3. Motivation
4. What you should not expect from this talk? • Code snippets • Programming language advertising • Framework advertising • Recipes
5. What I will cover in this talk? • Software Architecture • Object-Oriented principles • Design patterns • Mindset change
6. Software Architecture
8. “Software architecture refers to the high level structures of a software system, the discipline of creating such structures, and the documentation of these structures.” - Wikipedia
9. What exactly does framework-agnostic mean?
10. Code that works independent of frameworks.
11. Framework-agnostic does mean framework intolerant?
13. Why framework- agnostic code?
14. The web moves faster than you.
15. Framework-agnostic code is 
 more reusable than 
 framework-specific code.
16. Framework-agnostic code is 
 more scalable than 
 framework-specific code.
17. Framework-agnostic code is 
 more reliable than 
 framework-specific code.
18. Framework-agnostic code allows you to care about the most important thing!
19. Build an awesome product!
20. Software Design Evolution
21. Procedural Era (1994-2000)
22. Object-Oriented 2000-2004
23. Frameworks 2005-2009
24. PHP-FIG 2009
25. Composer 2012-2013
26. Components Era 2013-now
27. Component Driven Architecture
29. What is Component?
30. Famous PHP Components • Symfony\HttpFoundation • Zend\Cache • Illuminate\Container • League\Csv • Omnipay\Omnipay • Thousands of others…
31. Why Components?
32. Why Components? • Components are reusable • Components are extensible • Components are scalable • Components are testable • And we reduce the side-effects when another part of the application changes
33. Ok, so, how to?
34. Lets get a real world problem…
35. E-Commerce Platform
36. An e-commerce platform should… • Have products • Manage the stock of these products • Let customers buy something • Generate an order • Receive payments • Delivery the products • And so many other business rules
37. Domain Driven Design
38. –Vaughn Vernon “Developing software that delivers true business value is not the same as developing ordinary business software. Software that delivers true business value aligns with the business strategic initiatives.”
40. Why DDD?
41. Every Product should deliver some true value for its customers.
42. Every Product should evolve with its market, and your code should evolve together.
43. Domains in an e-commerce platform • Customers • Orders • Shipping • Payment • Products • Stock • Discount Coupons • etc…
44. Payments
45. In Payments, you can pay for… • An Order • A Service • A Donation • etc…
46. In Payments, you can pay with… • Credit card • Debit card • Ticket • EFT • Cryptocurrencies • etc…
47. In Payments, you can pay through… • Cielo • Rede • PagSeguro • MoIP • PayPal • Stripe • etc…
48. And, some payment processors could send you notifications about a given payment…
49. S.O.L.I.D.
50. Single Responsibility • A Payment Request • A Payment Result • A Gateway Implementation • Some payment processors specific implementations • etc…
51. Open/Closed Principle • PagSeguro has 2 different implementation models: Standard and Transparent. • I have a PagSeguro Adapter class that implements the Standard checkout. • Our customers needs Transparent payments too • I should be able to extend the PagSeguro class in order to create a Transparent adapter class
52. Liskov Substitution Principle • The Payment gateway should be able to process a payment using both the PagSeguro adapter as with the PagSeguro Transparent adapter.
53. Interface Segregation • Each payment service has specific rules like authentication, payment methods, installments, taxes, etc… • You should define these behaviors using client-specific interfaces • Authenticable Interface • Installments Interface • Offline Interface • Transparent Interface • etc…
54. Dependency Inversion • One should “depends upon abstractions, not concretions”. • Use Dependency Injection of the abstractions • Use DI containers to care about the concretion of these abstractions
55. Design Patterns
56. Creational • AbstractFactory • Builder • FactoryMethod • Prototype • SimpleFactory • etc…
57. Structural • Adapter • Bridge • DataMapper • DependencyInjection • Facade • Proxy • etc…
58. Behavioral • ChainOfResponsibility • Command • Iterator • Mediator • Observer • Visitor • etc…
59. Ok, understood, but, what about the frameworks?
61. Facades and Services
62. Facades and Services • Write the whole framework-specific code as Facades and Services • Inject and integrate it with the framework using tools like Dependency Injection Container, Service Container, etc… • If you need/want to move away from your current framework, you only need to write a new “specific service” that integrates your business component into the framework.
63. Frameworks are tools, not products.
64. Questions?
65. Thank You! Lucas Mendes 
 Software Architect at Tienda Nube Find me on Twitter: @devsdmf We’re hiring!