Tweet
Tweet

Slide 1

Slide 1 text

Framework-agnostic Applications A story about components Lucas Mendes 
 Software Architect at Tienda Nube Find me on Twitter: @devsdmf

Slide 2

Slide 2 text

$ whoami

Slide 3

Slide 3 text

Motivation

Slide 4

Slide 4 text

What you should not expect from this talk? • Code snippets • Programming language advertising • Framework advertising • Recipes

Slide 5

Slide 5 text

What I will cover in this talk? • Software Architecture • Object-Oriented principles • Design patterns • Mindset change

Slide 6

Slide 6 text

Software Architecture

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 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 9

Slide 9 text

What exactly does framework-agnostic mean?

Slide 10

Slide 10 text

Code that works independent of frameworks.

Slide 11

Slide 11 text

Framework-agnostic does mean framework intolerant?

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

Why framework- agnostic code?

Slide 14

Slide 14 text

The web moves faster than you.

Slide 15

Slide 15 text

Framework-agnostic code is 
 more reusable than 
 framework-specific code.

Slide 16

Slide 16 text

Framework-agnostic code is 
 more scalable than 
 framework-specific code.

Slide 17

Slide 17 text

Framework-agnostic code is 
 more reliable than 
 framework-specific code.

Slide 18

Slide 18 text

Framework-agnostic code allows you to care about the most important thing!

Slide 19

Slide 19 text

Build an awesome product!

Slide 20

Slide 20 text

Software Design Evolution

Slide 21

Slide 21 text

Procedural Era (1994-2000)

Slide 22

Slide 22 text

Object-Oriented 2000-2004

Slide 23

Slide 23 text

Frameworks 2005-2009

Slide 24

Slide 24 text

PHP-FIG 2009

Slide 25

Slide 25 text

Composer 2012-2013

Slide 26

Slide 26 text

Components Era 2013-now

Slide 27

Slide 27 text

Component Driven Architecture

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

What is Component?

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Why Components?

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

Ok, so, how to?

Slide 34

Slide 34 text

Lets get a real world problem…

Slide 35

Slide 35 text

E-Commerce Platform

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Domain Driven Design

Slide 38

Slide 38 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 39

Slide 39 text

No content

Slide 40

Slide 40 text

Why DDD?

Slide 41

Slide 41 text

Every Product should deliver some true value for its customers.

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Payments

Slide 45

Slide 45 text

In Payments, you can pay for… • An Order • A Service • A Donation • etc…

Slide 46

Slide 46 text

In Payments, you can pay with… • Credit card • Debit card • Ticket • EFT • Cryptocurrencies • etc…

Slide 47

Slide 47 text

In Payments, you can pay through… • Cielo • Rede • PagSeguro • MoIP • PayPal • Stripe • etc…

Slide 48

Slide 48 text

And, some payment processors could send you notifications about a given payment…

Slide 49

Slide 49 text

S.O.L.I.D.

Slide 50

Slide 50 text

Single Responsibility • A Payment Request • A Payment Result • A Gateway Implementation • Some payment processors specific implementations • etc…

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Liskov Substitution Principle • The Payment gateway should be able to process a payment using both the PagSeguro adapter as with the PagSeguro Transparent adapter.

Slide 53

Slide 53 text

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…

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Design Patterns

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

Ok, understood, but, what about the frameworks?

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

Facades and Services

Slide 62

Slide 62 text

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.

Slide 63

Slide 63 text

Frameworks are tools, not products.

Slide 64

Slide 64 text

Questions?

Slide 65

Slide 65 text

Thank You! Lucas Mendes 
 Software Architect at Tienda Nube Find me on Twitter: @devsdmf We’re hiring!