Il documento descrive l'architettura software del living lab e-suap, progettata per il cloud e altamente scalabile, con un forte focus su basse consumazioni di banda e approcci di sviluppa come TDD. La struttura modulare e disaccoppiata permette una chiara separazione tra logica di business e interfaccia utente, facilitando lo sviluppo e la manutenzione. Sono inoltre supportati standard come Microsoft TypeScript e HTML5, con un'integrazione fluida tra client e server, inclusa la gestione dei processi aziendali.

1. Living Lab
e-Suap
Architettura software generale

2. Caratteristiche principali
 Progettato completamente per il cloud (ma disponibile anche “on-premise”)
 Altamente scalabile grazie all’implementazione di un sistema di tipo “rich client” ed
all’utilizzo di un approccio Single-Page-Application (SPA).
 Basso consumo di banda per i round-trips server:
- Dopo aver scaricato ed aggiunto alla cache una prima volta le view ed i file javascript,
solo i dati viaggeranno in rete, senza alcuna informazione relativa al change tracker.
 Utilizzo di approcci di tipo “Rich full domain” e “API Data-Centric” in maniera simile a
quanto accade per le smart applications client-server basate sul .NET framework o Java.
 Sviluppo RAD (Rapid application development) con forte integrazione con Visual Studio
2013 e Typescript.
 Utilizzo delle potenzialitàofferte daHTML5 e svilppo in stile RIA Services: basso consumo
di banda, maggiore manutenibilità del codice, ecc.
 Client-Side development experience, in maniera simile a quanto accade con Silverlight e
WPF (Windows Presentation Foundation).
 Sviluppo di tipo Test Driven (TDD) grazie anche all’adozione del pattern MVVM e
all’applicazione dei principi dettati dal DDD (Domain-driven design)
 Presenza di numerosi casi di test: viene favorita una continua integrazione.

3. Layered Architecture
Il modello di dominio, la logica applicativa e di business, l’interfaccia utente e tutti gli altri layers
sono fortemente isolati. Le applicazioni sono organizzate in diversi domini, moduli e livelli.
Ciascun layer è altamente “coeso” e dipende solo dai livelli inferiori. Ogni “strato” è d’altro canto
fortemente disaccoppiato dai restanti. La logica applicativa e di business è isolata dalla user-
interface e dai layers relativi all’infrastruttura. I diversi domini sono legati tramite interfacce di
servizio e connessi attraverso l’utilizzo di pattern publish/subscribe su un Enterprise Service Bus,
che consente un maggiore disaccoppiamento, scalabilità e migliore distribuzione dei carichi di
lavoro.
 Entità e value objects definiscono lo stato di ogni singolo oggetto;
 Gli eventi di dominio passano tutti attraverso l’Enterprise Service Bus e raggiungono i
consumers attraverso le porte opportune;
 Services e controllers rendono la logica di business disponibile all’esterno (con appropriate
misure di sicurezza)

4.  Un’architettura modulare è garantita per ogni componente all’interno del proprio
livello(layer) di appartenenza. Ogni modulo ha uno sviluppo indipendente ed è debolmente
accoppiato con gli altri componenti nel sistema.
 I Repository patterns disaccoppiano la logica di business dalla “persistence” e dai servizi
esterni tramite opportune entità di dominio:
- Ciascun “consumer” vede solo una in-memory collection di tutti gli oggetti e tipi
aggregati;
 Grazie all’utilizzo dell’interfacciaIRepository<> edallacorrispondente generica interfaccia
UOW(unit of work) ogni entità di dominio è automaticamente aggiungibile, rimovibile e
ricercabile tramite “Rich Criteria Object”: di conseguenza gli sviluppatori possono
mantenere la logica applicativa strettamente focalizzata sui requisiti di business;
 Deepmodeling: L’approccio model-first conferisce all’intera architettura una caratteristica
di “Supple Design”. Utilizzando lo stesso ambiente di sviluppo sia per la scrittura del
codice, sia per la progettazione, gli sviluppatori possono avere una più chiara prospettiva di
ciò che deve essere implementato, grazie a strumenti di refactoring e remodeling più
semplici e presenti direttamente all’interno dell’ambiente di sviluppo. L’effetto netto può
essere così riassunto:
1) I behaviours sono più evidenti
2) I costi delle modifiche sono ridotti
3) L’ambiente di sviluppo è più comodo e piacevole per gli sviluppatoriù
 Grazie ad una sicurezzaclaim-based, un anti-corruption orthogonal layer forniscefeaturesdi
sicurezzastateless che viaggiano condatagrammi message-orientedattraverso diversi layers
verso il client e viceversa.

5. RAD DEVELOPMENT
 Behaviour e test driven development: i test sono parte integrante dell’applicazione e sono
direttamente ospitati all’interno dell’ambiente di sviluppo.
 La piattaforma è stata sviluppata basandosi sull’esperienza delle WPF e servizi RIA.
 Supporto First-Class Microsoft Typescript
 Le data entities client-side sono state generate attraverso template T4 direttamente dai Full
Entity Framework Models:
 Come ORM è stato infatti adottato Entity Framework, con pieno supporto alle classi
Typescript lato client: ereditarietà, astrazione, tipi complessi, approccio code-first o model-
first. L’Object Change Tacking client side è stato implementato direttamente nel client della
single page application, basato su Javascript.

6.  Scenari client-side offline, con la piena persistenza dei dati e supporto al change tracking;
 Supporto alle classi parziali per dati aggregati e UI-oriented value objects, per mezzo di
serialization surrogates.
 Basato su Open Source Hot Towel template, Durandal, Knockout etc.
 Implementazione veloce e potente dell’interfaccia utente , MVVM testing e molti altri
vantaggi.
 Supporto Html5 e compatibilità per tutti i tipi di browser e di dispositivi.
 Grazie all’UI compontent “indirection” è possibile cambiare vista per i diversi dispositivi
semplicemente cambiando la template library, senza modificare il codice.
 Rigorosa implementazione del pattern template.
 Riuso di tutti i componenti dell’interfaccia utente, dai singoli template fino alle viste
complesse, grazie alle librerie open-source Durandal e Knockout.
 La User Interface ha il proprio object model, come accade XAML.
 All’interno del browser, il runtime user interface designer legge e scrive in JAML
(abbreviazione per JSON Application Markup Language).
 Validazione ed altre features vengono supportate dalle tecniche repository-based.
 Grazie all’implementazione della sicurezza claim-based, in qualsiasi istante il security
context dell’utente che ha causato un’azione di trasformazione è reso sempre disponibile
all’esecuzione del codice lato server.

7. Business Processes
 Le entità dei processi di business sono definite in un “Common domain module”.
 La soluzione proposta non è strettamente legata ad uno specifico Business Process Engine.
 E’ possibile scegliere differenti soluzioni per le implementazioni di business process long-
term.
 Una semplice implementazione per Microsoft BizTalk Server è fornita “out of the box”:
 Monitoraggio dell’attività di business (BAM).
 KPI: I progetti BAM supportano l’integrazione con i MS SQL analysis services. Il portale
BAM fornisce tabelle Pivot e cubi che possono anche essereesportati dai BI tools e possono
essere integrati all’interno di Excel consentendo una visualizzazione real-time delle attività
dei business processes.
 Graphic IDE and Parties (users) possono essere gestiti con Visual Studio e BTS
Administration Console oppure in maniera programmatica, grazie ad un API disponibile out
of the box.
 Le componenti di processo sono assemblies che possono essere memorizzate, distribuite e
riusate attraverso “port modifiers” pubblici, privati o interni.