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
- NO: sono un'implementazione del command pattern - Command Query Separation (https://martinfowler.com/bliki/CommandQuerySeparation.html)
- NO: tell don't ask (magari tiriamo un'eccezione se va male) (https://robots.thoughtbot.com/tell-dont-ask)
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
Via Guglielmo Marconi 20, 37012 Bussolengo - Verona https://www.devinterface.com/it
https://twitter.com/devinterface
https://github.com/devinterface
info@devinterface.com stefano.mancini@devinterface.com
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.
