Upload
mauro-servienti
View
442
Download
0
Embed Size (px)
DESCRIPTION
Talk at Xe.Net
Citation preview
utile e sostenibile
L'architettura di un'applicazione in un mondo basato su servizi: cosa fare e cosa non fare
Who’s Mauro?
Mauro ServientiMicrosoft 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…
Appassionato di: ALM e metodologie agili
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»:
Agenda…? :-)
• Verità e Assiomi (…pretenzioso l’amico);• Perché mai un servizio?• A-to-mi-co;• Il bagaglio…per un viaggio;• …un viaggio specifico;
• 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…
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?
Agenda…? :-)
• Verità e Assiomi (…pretenzioso l’amico);• Perché mai un servizio?• A-to-mi-co;• Il bagaglio…per un viaggio;• …un viaggio specifico;
Security/policyil front-end non deve poter accedere alla base dati;
Più di un’applicazione fruisce dei nostri dati;
Dobbiamo poter scalare orizzontalmente(ed è costoso e/o complesso scalare orizzontalmente un
database)
Dobbiamo aggregare fonti dati eterogenee al fine di renderle fruibili a diverse applicazioni senza spalmare su ogni applicazione la complessità dell’aggregazione
Motivi e Bisogni
…e bla bla bla…
sicuramente ci sono una montagna di buonissimi
motivi…
Agenda…? :-)
• Verità e Assiomi (…pretenzioso l’amico);• Perché mai un servizio?• A-to-mi-co;• Il bagaglio…per un viaggio;• …un viaggio specifico;
A-to-mi-co…
• 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;
Quindi?!?!?!
Nel modello mentale dell’utente le transazioni non esistono;
Non si può appendere un quadro in transazione…
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
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
…and least but not last…
IdempotenzaSe cercate di ripresentare la stessa pratica
edilizia più volte non è che vi costruiscono più case…
Take away
…la cruda realtà…
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.
Agenda…? :-)
• Verità e Assiomi (…pretenzioso l’amico);• Perché mai un servizio?• A-to-mi-co;• Il bagaglio…per un viaggio;• …un viaggio specifico;
è tutto in dipendenza del viaggio…
Credo sia chiaro a tutti che sono sciatori….
Quanti viaggi ci sono?
Avrebbe senso lo stesso bagaglio?
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
Agenda…? :-)
• Verità e Assiomi (…pretenzioso l’amico);• Perché mai un servizio?• A-to-mi-co;• Il bagaglio…per un viaggio;• …un viaggio specifico;
…un viaggio specifico
Ho detto sciatori?….scusate intendevo alpinisti.
Produrreste mai questo?
Allora perché fate questo?
public interface IApplicationService {
void Save( DomainEntity entity );}
Che cosa manca di fondamentale?
It’s all about state
what
how
criminal intent
• 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;
Take away
…a meno che…
Piccolo spazio pubblicità…«messaggi»
…è un mondo dificile…
«duale»
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 security; Take away
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
2 aggregate…?!?!?…per una cosa sola…!!!
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
Welcome to the DDD World.
Andiamo a mangiare…
Domande?