utile e sostenibile

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…

//[email protected]

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…? :-)


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…? :-)


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…? :-)


è 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…? :-)


…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?

utile e sostenibile

Technology