Service Objects

Pattern & Antipattern

(solo per oggi in Ruby on Rails)

BUG - 21/11/2018

Stefano Mancini

Abstract

Da qualche anno a questa parte il concetto di Fat models e Skinny controllers è venuto meno. E' sempre più marcata la volontà di spostare la business logic applicativa in appositi servizi, creati ad hoc per poter essere riutilizzati nell'applicazione.

 

Vedremo come implementare un Service Object e quali possono essere i comuni utilizzi nelle moderne web applications.


Ma i Service Object sono veramente la soluzione definitiva? O si può tranquillamente farne a meno? Analizzeremo pattern, antipattern ed interpretazioni.

 

Marchetta

Text

DevInterface

> Stefano Mancini, co-founder e CTO di DevInterface

> DevInterface SRL, nata nel 2011

> Sviluppo web e mobile

  • web applications
  • system integrations
  • ecommerce
  • microservices
  • prodotti
    • ToDoMarriage
    • CloudBSC
    • PlinioCMS

Timeline Tecnologie

> 2011 - Ruby on Rails

> 2012 - Django

> 2015 - Angularjs, Ionic

> 2016 - NodeJS, Vue.js

> 2017 - React, Angular

> 2018 - React Native, PHP

> 2019 - Go

> 2020 - the next big thing!

Timeline architetture

> 2011 - monolita era

 

> 2015 - microservices era

 

> fine 2016 oggi - API + SPA era

We are hiring!

2011: registrazione utenti

Fat models & skinny controllers

> model con callback

 

> il model persiste il dato, lo valida, chiama metodi di altri model, effettua logica di business, invia email, fa tutto


> ma se creo un utente dalla console?

 

> ma se creo un utente dalla dashboard di un admin?

 

> e se devo andare in edit dell'utente?

2013: registrazione utenti

Slimmer models & !so skinny controllers

 

> un po' di logica nel model e un po' nel controller


> ma se ho anche il controller API? Ok, lo estendo

 

> ma se devo creare un utente anche da un messaggio RabbitMQ?

 

2015: registrazione utenti

Service Objects

> 15 novembre 2002: Martin Fowler - Patterns of Enterprise Application Architecture

 

 

 

Service Objects

"A Service Layer defines an application’s boundary and its set of available operations from the perspective of interfacing client layers. It encapsulates the application’s business logic, controlling transactions and coordinating responses in the implementation of its operations.

Randy Stafford

 

In breve, in una architettura MVC, un Service Object deve incapsulare la logica di business tra il controller ed il model.

 

Service Objects

Disappointing as it is, many of the use cases in an enterprise application are fairly boring “CRUD” (create, read, update, delete) use cases on domain objects—create one of these, read a collection of those, update this other thing. My experience is that there's almost always a one-to-one correspondence between CRUD use cases and Service Layer operations.

The application's responsibilities in carrying out these use cases, however, may be anything but boring. Validation aside, the creation, update, or deletion of a domain object in an application increasingly requires notification of other people and other integrated applications. These responses must be coordinated, and transacted atomically, by Service Layer operations.

http://www.informit.com/articles/article.aspx?p=1398617&seqNum=4

Caratteristiche principali

> classi: PORO

 

> semplicità: hanno un solo punto di ingresso


> un unico scopo: Single Responsibility Principle

Caratteristiche in discussione

ritornano un valore?

Caratteristiche in discussione

  • SI, ma allora chiamiamolo Interactor

ritornano un valore?

Caratteristiche in discussione

possono chiamare altri Service Objects?

 

> NO, Single Responsibility Principle https://en.wikipedia.org/wiki/Single_responsibility_principle


> SI, ma allora chiamiamolo Flow o UseCase o Orchestrator

Caratteristiche in discussione

> validano gli input in ingresso?

 

> aprono e chiudono una transazione? se si, cosa succede se chiamano altri Service Objects?

Benefici

> astrazione tra la presentazione dei dati ed il dato stesso (posso migrare il mio User da tabella sul database a API remota e non devo modificare nulla (o quasi) dal controller in su)

 

> sono chiari i parametri in ingresso


> riusabilità del codice non solo nel controller, ma anche nel backend

 

Benefici

> pulizia del codice

 

> implementa la business logic, fa chiaramente ciò che mi aspetto debba fare


> testabilità, è un PORO

   Bene, ma in DevInterface come lo usate?

> PORO


> un solo punto di ingresso, no hash


> valida l'input


> torna il successo, l'insuccesso ed il risultato


> se necessario chiama altri service objects


> non autorizza l'azione (lo fa il controller)


> gestisce la transazione se necessario

OK, fuori il codice

And finally...

GRAZIE!

 

DevInterface SRL

Service Objects, pattern & antipattern

By DevInterface SRL

Service Objects, pattern & antipattern

Da qualche anno a questa parte il concetto di Fat models e Skinny controllers è venuto meno. E' sempre più marcata la volontà di spostare la business logic applicativa in appositi servizi, creati ad hoc per poter essere riutilizzati nell'applicazione. Vedremo come implementare un Service Object e quale possano essere i comuni utilizzi nelle moderne web applications. Ma i Service Object sono veramente la soluzione definitiva? O si può tranquillamente farne a meno? Analizzeremo pattern, antipattern ed interpretazioni.

  • 91

More from DevInterface SRL