Framework-Agnostic Applications - A story about components

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

7a736764e6d6c830c049bdc2be34ec19?s=128

Lucas Mendes

March 06, 2018
Tweet

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

  7. None
  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?

  12. None
  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

  28. None
  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.”
  39. None
  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?

  60. None
  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!