Framework-agnostic Code - A story about business and code

Slide 1

Slide 1 text

Framework-agnostic Code A story about business and code Lucas Mendes   Product Owner at Tienda Nube Find me: @devsdmf

Slide 2

Slide 2 text

$ whoami

Slide 3

Slide 3 text

PHP code over the years…

Slide 4

Slide 4 text

Procedural Era (1994-2000)

Slide 5

Slide 5 text

Object-Oriented 2000-2004

Slide 6

Slide 6 text

Frameworks 2005-2009

Slide 7

Slide 7 text

PHP-FIG 2009

Slide 8

Slide 8 text

Composer 2012-2013

Slide 9

Slide 9 text

Components Era 2013-now

Slide 10

Slide 10 text

Agnostic?

Slide 11

Slide 11 text

“Someone who is doubtful or noncommittal about something”

Slide 12

Slide 12 text

“Someone who is not able to commit to an opinion about something that does not know”

Slide 13

Slide 13 text

What exactly does framework-agnostic mean?

Slide 14

Slide 14 text

Code that works independent of frameworks.

Slide 15

Slide 15 text

Framework-agnostic does mean framework intolerant?

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Why framework- agnostic code?

Slide 18

Slide 18 text

The web moves faster than you.

Slide 19

Slide 19 text

Framework-agnostic code is   more reusable than   framework-speciﬁc code.

Slide 20

Slide 20 text

Framework-agnostic code is   more scalable than   framework-speciﬁc code.

Slide 21

Slide 21 text

Framework-agnostic code is   more reliable than   framework-speciﬁc code.

Slide 22

Slide 22 text

Framework-agnostic code allows you to care about the product-speciﬁc code!

Slide 23

Slide 23 text

How to framework- agnostic code?

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

Software Design

Slide 26

Slide 26 text

“Software Design is the process by which an agent creates an speciﬁcation of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints.” - Wikipedia

Slide 27

Slide 27 text

Software Architecture

Slide 28

Slide 28 text

“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

Slide 29

Slide 29 text

Component Driven Architecture

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

What is Component?

Slide 32

Slide 32 text

Famous PHP Components • Symfony\HttpFoundation • Zend\Cache • Illuminate\Container • League\Csv • Omnipay\Omnipay • Thousands of others…

Slide 33

Slide 33 text

Why Components?

Slide 34

Slide 34 text

Why Components? • Components are reusable • Components are extensible • Components are scalable • Components are testable • And we reduce the side-eﬀects when another part of the application changes

Slide 35

Slide 35 text

Domain Driven Design

Slide 36

Slide 36 text

–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.”

Slide 37

Slide 37 text

Why DDD?

Slide 38

Slide 38 text

Every Product should deliver some true value for its customers.

Slide 39

Slide 39 text

Every Product should evolve with its market, and your code should evolve together.

Slide 40

Slide 40 text

Looking at a real world problem…

Slide 41

Slide 41 text

E-Commerce Platform

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Domains

Slide 44

Slide 44 text

Domains in an e-commerce platform • Customers • Orders • Shipping • Payment • Catalog • Discount Coupons • etc…

Slide 45

Slide 45 text

Bounded Contexts

Slide 46

Slide 46 text

Payments

Slide 47

Slide 47 text

You can pay for… • A Product • A Service • A Ticket • A Donation • etc…

Slide 48

Slide 48 text

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…

Slide 49

Slide 49 text

In Payments, you can pay through… • PayPal • Stripe • Wirecard • PagSeguro • Mercado Pago • etc…

Slide 50

Slide 50 text

S.O.L.I.D.

Slide 51

Slide 51 text

Single Responsibility • A Payment Type • A Payment Method • A Payment Gateway • A Payment Request • A Payment Result • etc…

Slide 52

Slide 52 text

Open/Closed Principle • PagSeguro has 2 diﬀerent 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.

Slide 53

Slide 53 text

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 diﬀerent payment methods, if it supports.

Slide 54

Slide 54 text

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…

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

Design Patterns

Slide 57

Slide 57 text

Creational • AbstractFactory • Builder • FactoryMethod • Prototype • SimpleFactory • etc…

Slide 58

Slide 58 text

Structural • Adapter • Bridge • DataMapper • DependencyInjection • Facade • Proxy • etc…

Slide 59

Slide 59 text

Behavioral • ChainOfResponsibility • Command • Iterator • Mediator • Observer • Visitor • etc…

Slide 60

Slide 60 text

Ok, understood, but, what about the frameworks?

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

Facades and Services

Slide 63

Slide 63 text

Facades and Services • Write the whole framework-speciﬁc 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.

Slide 64

Slide 64 text

Frameworks are tools, not products.

Slide 65

Slide 65 text

Questions?

Slide 66

Slide 66 text

Thank You! Lucas Mendes   Product Owner at Tienda Nube Find me: @devsdmf We’re hiring!