Framework-agnostic Code - A story about business and code

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 Conference 2018.

Transcript

1. Framework-agnostic Code A story about business and code Lucas Mendes 
 Product Owner at Tienda Nube Find me: @devsdmf
2. $ whoami
3. PHP code over the years…
4. Procedural Era (1994-2000)
5. Object-Oriented 2000-2004
6. Frameworks 2005-2009
7. PHP-FIG 2009
8. Composer 2012-2013
9. Components Era 2013-now
10. Agnostic?
11. “Someone who is doubtful or noncommittal about something”
12. “Someone who is not able to commit to an opinion about something that does not know”
13. What exactly does framework-agnostic mean?
14. Code that works independent of frameworks.
15. Framework-agnostic does mean framework intolerant?
17. Why framework- agnostic code?
18. The web moves faster than you.
19. Framework-agnostic code is 
 more reusable than 
 framework-specific code.
20. Framework-agnostic code is 
 more scalable than 
 framework-specific code.
21. Framework-agnostic code is 
 more reliable than 
 framework-specific code.
22. Framework-agnostic code allows you to care about the product-specific code!
23. How to framework- agnostic code?
25. Software Design
26. “Software Design is the process by which an agent creates an specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints.” - Wikipedia
27. Software Architecture
28. “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
29. Component Driven Architecture
31. What is Component?
32. Famous PHP Components • Symfony\HttpFoundation • Zend\Cache • Illuminate\Container • League\Csv • Omnipay\Omnipay • Thousands of others…
33. Why Components?
34. 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
35. Domain Driven Design
36. –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.”
37. Why DDD?
38. Every Product should deliver some true value for its customers.
39. Every Product should evolve with its market, and your code should evolve together.
40. Looking at a real world problem…
41. E-Commerce Platform
42. An e-commerce platform should… • Have products • Manage the stock of these products • Allow customers to buy something • Generate an order • Receive payments • Ship the orders • And so many other business rules
43. Domains
44. Domains in an e-commerce platform • Customers • Orders • Shipping • Payment • Catalog • Discount Coupons • etc…
45. Bounded Contexts
46. Payments
47. You can pay for… • A Product • A Service • A Ticket • A Donation • etc…
48. You can pay with… • Credit card (Visa, Mastercard, Amex, Diners, …) • Debit card (Visa Electron, Mastercard, Elo, …) • EFT (Thousands of banks) • Ticket (Thousands of issuers) • Cryptocurrencies Exchange (Bitcoin, …) • etc…
49. In Payments, you can pay through… • PayPal • Stripe • Wirecard • PagSeguro • Mercado Pago • etc…
50. S.O.L.I.D.
51. Single Responsibility • A Payment Type • A Payment Method • A Payment Gateway • A Payment Request • A Payment Result • etc…
52. Open/Closed Principle • PagSeguro has 2 different implementation models: Standard and Transparent. • A PagSeguro class that implements the Standard checkout. • I should be able to extend the PagSeguro class in order to implement the Transparent behaviour.
53. Liskov Substitution Principle • The Payment Processor should be able to process payments for orders, services, tickets, or anything payable. • The Payment Processor also should be able to work with the PagSeguro class as well with the PagSeguro Transparent class. • And the Payment Gateway should be able to process payments through different payment methods, if it supports.
54. Interface Segregation • Each Payment Gateway has specific requirements like authentication, supported payment methods, installments, taxes, etc… • You should define these behaviours using client-specific interfaces, like Authenticable Interface, Installments Interface, Offline Interface, Transparent, Interface, etc…
55. Dependency Inversion • One should “depends upon abstractions, not concretions”. • A Payment Processor must expect an implementation of a Gateway Interface instead of an instance of a PagSeguro class. • A Payment Processor must expect a Payable Interface instead of an instance of an Order class. • Use Dependency Injection of the abstractions. • Use DI containers to care about the concretion of these abstractions
56. Design Patterns
57. Creational • AbstractFactory • Builder • FactoryMethod • Prototype • SimpleFactory • etc…
58. Structural • Adapter • Bridge • DataMapper • DependencyInjection • Facade • Proxy • etc…
59. Behavioral • ChainOfResponsibility • Command • Iterator • Mediator • Observer • Visitor • etc…
60. Ok, understood, but, what about the frameworks?
62. Facades and Services
63. 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 change the service that integrates your business component with the framework.
64. Frameworks are tools, not products.
65. Questions?
66. Thank You! Lucas Mendes 
 Product Owner at Tienda Nube Find me: @devsdmf We’re hiring!