Il documento fornisce linee guida sull'architettura delle applicazioni basate su servizi, enfatizzando l'importanza dell'atomicità, della compatibilità dei servizi e del modello mentale degli utenti. Viene sottolineato che i servizi devono essere autonomi e che ogni servizio deve essere pensato nel contesto specifico dell'uso, evitando generalizzazioni che possono compromettere la qualità. Infine, l'autore discute l'importanza di una gestione consapevole dei confini nei dati e delle pratiche di scrittura e lettura nei servizi.

1. utile e sostenibile
L'architettura di un'applicazione in un mondo basato
su servizi: cosa fare e cosa non fare

2. Mauro Servienti
Microsoft MVP - Visual C#
Qualcuno sostiene che io sia un «architetto»
in realtà ci provo e basta …quindi sempre «mason»
sono…che poi…c’è anche qualcuno che sostiene
che gli architetti non esistono…
//milestone.topics.it
mauro@topics.it
Appassionato di: ALM e metodologie agili
Who’s Mauro?

3. Avviso ai naviganti
• È un mondo «nuovo» anche per il sottoscritto
– Lo stile della presentazione non la ciccia…in parte
anche la ciccia :-)
• Tutto quello che dirò a prescindere da come lo
dirò sono un set di linee guida non la verità
assoluta, linee guida che devono essere calate nel
contesto del progetto;
– Insomma…non sono il dottore :-P
• Attenti al simbolino del «take away»:

4. • Verità e Assiomi (…pretenzioso l’amico);
• Perché mai un servizio?
• A-to-mi-co;
• Il bagaglio…per un viaggio;
• …un viaggio specifico;
Agenda…? :-)

5. • i servizi si usano se servono non perché fa figo;
– Questa è molto minimal…;
• l’atomicità deve essere garantita sempre, magari non si può
parlare di transazioni, ma l’atomicità (anche apparente) delle
operazioni ci deve essere sempre;
– Il driver è il bisogno del nostro utente;
• ogni volta che attraversate un confine c’è un costo notevole
valutate bene cosa portate con voi;
– Lo stige è un viaggio senza ritorno… :-)
• cercare di essere vagamente generici (ad esempio esponendo in
maniera banale la CRUD) non serve a nulla;
– Provate a chiedere all’ufficio postale se vi cerca un indirizzo…

6. Vi ricorda qualcosa?
• Boundaries are Explicit
– Viaggiando attraversate dei confini…ben noti;
• Service compatibility is determined based on
policy:
– Quando chiedete qualcosa a qualcuno sapete cosa
chiedere oppure sapete cosa chiedere per sapere cosa
chiedere… :-)
• Services share schema and contract, not class
– …non mi viene un esempio… :-/
• Services are Autonomous:
– Se sostituite l’impeigato allo sportello cosa cambia?

7. • Verità e Assiomi (…pretenzioso l’amico);
• Perché mai un servizio?
• A-to-mi-co;
• Il bagaglio…per un viaggio;
• …un viaggio specifico;
Agenda…? :-)

8. Security/policy
il front-end non deve poter accedere alla base dati;

9. Più di un’applicazione fruisce dei nostri dati;

10. Dobbiamo poter scalare orizzontalmente
(ed è costoso e/o complesso scalare orizzontalmente un
database)

11. Dobbiamo aggregare fonti dati eterogenee al fine di
renderle fruibili a diverse applicazioni senza spalmare
su ogni applicazione la complessità dell’aggregazione

12. …e bla bla bla…
sicuramente ci sono una
montagna di buonissimi
motivi…
Motivi e Bisogni

13. • Verità e Assiomi (…pretenzioso l’amico);
• Perché mai un servizio?
• A-to-mi-co;
• Il bagaglio…per un viaggio;
• …un viaggio specifico;
Agenda…? :-)

14. • L’utente ha il suo
concetto di atomicità;
• Il modello mentale
dell’utente è sacro;
• Ogni volta che si
attraversa un confine le
transazioni sono il male;
A-to-mi-co…

15. Nel modello mentale
dell’utente le
transazioni non
esistono;
Non si può appendere
un quadro in
transazione…
Quindi?!?!?!

16. the user-mental-model way (1)
• compensazione:
1. Ciò che non ha effetti collaterali (abbandono);
2. Ciò che è cancellabile in maniera definitiva;
3. Ciò che è per forza transazionale (orticello);
• Preparo tutti i documenti per la pratica edilizia;
• Avvio la richiesta della pratica edilizia;
• …non trovo nulla che debba essere «transazionale»;
Take away

17. the user-mental-model way (2)
• messaggio & fotografia;
1. Inserisco un’operazione;
2. Inserisco un’operazione contraria;
3. Faccio una fotografia, cancello le operazioni fatte
(se serve) e ricomincio;
• La contabilità funziona così…da sempre;
Take away

18. …and least but not
last…
Idempotenza
Se cercate di ripresentare la stessa pratica
edilizia più volte non è che vi costruiscono più
case…
Take away

19. Le transazioni servono perché abbiamo a che
fare con un database relazionale la cui struttura
dei dati ha un’atomicità molto diversa (e spesso
obbligata) dal modello mentale dell’utente.
Questo ci porta, da pigri, a giovare delle
transazioni…anche fuori dall’orticello.
…la cruda realtà…

20. • Verità e Assiomi (…pretenzioso l’amico);
• Perché mai un servizio?
• A-to-mi-co;
• Il bagaglio…per un viaggio;
• …un viaggio specifico;
Agenda…? :-)

21. Credo sia chiaro a tutti che sono sciatori….
è tutto in dipendenza del viaggio…

22. Quanti viaggi ci sono?

23. Avrebbe senso lo
stesso bagaglio?

24. Aggregate…che non vuol dire aggregate
• I confini devono essere netti, altrimenti le
spezie si mischiano;
• Ci sono delle spezie che sono il risultato di un
mix…ma sono delle nuove spezie diverse;
• Brutalmente detto significa che avete più
rappresentazioni dello stesso dato per «use
case» diversi…ma è veramente lo stesso dato?
Take away

25. • Verità e Assiomi (…pretenzioso l’amico);
• Perché mai un servizio?
• A-to-mi-co;
• Il bagaglio…per un viaggio;
• …un viaggio specifico;
Agenda…? :-)

26. Ho detto sciatori?….scusate intendevo alpinisti.
…un viaggio specifico

27. Produrreste mai questo?

28. Allora perché fate questo?
public interface IApplicationService
{
void Save( DomainEntity entity );
}
Che cosa manca di fondamentale?

29. It’s all about state

30. • Cosa, Perché e Come rappresentano
le intenzioni;
• Save( Object ) non dichiara nulla delle
intenzioni, o magari non dichiara
abbastanza;
• ChangeCustomerAddress è molto più
esplicativo;
• La generalizzazione porta
inevitabilmente alla perdita di
controllo;
• I contratti di un servizio sono il posto
sbagliato per generalizzare altrimenti
finite con il chiedere l’indirizzo al
postino;
criminal intent Take away

31. …a meno che…
Piccolo spazio pubblicità…
«messaggi»

32. …è un mondo dificile…
«duale»

33. duale: lettura
• la “catena” delle operazioni che
portano il dato a chi ne ha
bisogno, nella forma in cui ne ha
bisogno, deve essere il più corta
possibile;
• Più la catena è lunga più si tende a
generalizzare:
– Limiti: che portano a sacrificare la
qualità a favore dei costi;
– Con i servizi i costi sono già alti quindi
sacrificare è solo controproducente;
– l’unica cosa che ha molto senso
inserire nella pipeline di lettura è la Take away
security;

34. duale: scrittura
• La scrittura ha molto senso che segua una
strada diversa, con servizi diversi;
– Con tutta la «pipeline» che serve;
• Fondamentale, in scrittura, è cambiare
punto di vista, non più in termini di “salva
questo grafo di oggetti” ma in termini di
“porta il tuo (del servizio) grafo dallo stato
in cui è a questo nuovo stato”;
– CQRS e Event Sourcing;
• Snapshop e ChangeSet
– abbiamo una situazione nota (uno Snapshot)
e dato un set di modifiche (ChangeSet)
vogliamo passare ad una nuova situazione
nota;
Take away

35. 2 aggregate…?!?!?
…per una cosa sola…!!!

36. per l’utente è uno solo
• Costa? moltissimo;
– Skill;
– Codice, tanto codice (ma noi
abbiamo i tool);
• Costa? pochissimo;
– Sul medio-lungo termine;
– È molto più manutenibile;
– È molto più flessibile;
Take away

37. Andiamo a mangiare…
Domande?
Welcome to the DDD World.