Capita all'inizio di un progetto di non conoscerne a pieno il dominio e non poterne prevedere l'evoluzione. F24 ZeroCode al primo giorno in cui è stato presentato al gruppo di lavoro non doveva essere niente di più che un contenitore di deleghe F24. poi sono cambiate tante cose. .

1. F24ZeroCodeZeroErrori
Emanuele Garofalo
From sketch to production

2. Di cosa parleremo

3. Agenda
• Esplorazione del dominio
– Dall’idea ad una parete piena di post-it
• Context Map
– Requisiti dei singoli contesti e come abbiamo
risposto agli stessi
• Produzione
– Facile o difficile?

4. Giorno 1: idea
• Abbiamo pensato ad un nuovo progetto
– Codename ZeroCode (dopo F24ZZ)
• L’idea di fondo è che sia un contenitore di F24 a
disposizione degli sportelli bancari per velocizzare
il processo di pagamento allo sportello.
• Lo sportello, al completamento del pagamento, ci
farà sapere che il pagamento è avvenuto
Facile no?!

5. Ciclo classico
Produttori di
deleghe F24
PSP
Contribuente

6. Ciclo F24ZZ
Produttori di
deleghe F24
PSP
Contribuente
F24ZZ
Facile no?!

7. Giorno 1: idea
NO!

8. Facciamo un passo indietro…
Q:
A:
Event Storming is a workshop format
for quickly exploring complex business
domains.
Cit: Alberto Brandolini (link alla fine)
Come posso esplorare un dominio che mi
è sconosciuto facendo emergere nel più
breve tempo possibile i requisiti che sono
scontati per gli stackholder?

9. Giorno 2: EventStorming
• Il primo errore
– «4 post-it in croce»
Delega Caricata
Delega Pagata
Delega Stornata
Paga Delega
Storna Delega
Storna Delega

10. Giorno 3: EventStorming «fatto meglio»

11. Giorno 4: EventStorming «definitivo»

12. Context Map
Gestione
Contratti
Erogazione /
Trattamento
deleghe
Forniture
Massive
Contabilità
HD

13. I Numeri
Q:
A: Ci aspettiamo di avere 40Mln di deleghe e 1Mln di
transazioni nel giorno di picco (6Mln durante tutto
l’anno)
Ok cosa vorremmo ce lo siamo "detti" ma quali sono
le previsioni per questa roba? Come dimensioniamo
il tutto?

14. Il nostro primo aggregato (2.0)

15. Trattamento Deleghe
• Requisiti non funzionali:
– Scalabilità (Tempo di risposta < 2 sec)
– Sicurezza
– RPO & RTO  minuti (se possibile 0) 
– High Availability

16. Trattamento Deleghe - le nostre scelte
• Mutua Autenticazione
• Messaging per scalare orizzontalmente
• CQRS per garantirci la consistenza dell’aggregato e
la maneggevolezza di un read model agnostico
rispetto al salvataggio
• Accettare di essere «in fine consistenti»
• CommandLog oltre all’EventLog in altro
datacenter per replicare i comandi fuori «backup»
• Azure per garantirci SLA accettabili senza
richiedere sforzi infrastrutturali da parte nostra
• Rebus per «wrappare» il transport

17. Trattamento Deleghe
Azure
Deliver
Rebus
Payment
Rebus
Feed
Rebus
Azure Service Bus
Worker
Service
Rebus
E
F
Sql Azure (limite imposto)
PostgreSQL (limite imposto)
Nel prossimo futuro
E
F
Sql Azure (limite imposto)
PostgreSQL (limite imposto)
Nel prossimo futuro
Write Model
Read Model
Guardians

18. Forniture Massive
• Requisiti funzionali a maggior impatto
– Non modificare i gestionali dei fornitori
– Adattabilità a diversi formati di forniture
– Per le forniture manuali fornire uno strumento in grado di
guidare durante la lavorazione e calato nei processi aziendali
• Controlli di qualità
• Monitoraggio dei processi
• Rispetto dei SLA
– Per le forniture «standard» eseguire un processo automatico
che però sia anche monitorabile
• Requisiti non funzionali:
– Scalabilità
– RPO & RTO in Ore

19. Forniture Massive – Le nostre scelte
• Microservices
• Creare degli interpreti per i file prodotti dai
verticali (Mapper)
• Projection degli eventi relativi alle forniture su un
read model delle forniture massive a supporto
dell’applicazione di monitoring (o auditing)
• Allarmi in caso di superamento di una delle
tempistiche all’interno dello SLA

20. Forniture Massive
Sql Azure
Ricezione
sFTP Server
Rebus
Rabbit MQ
Mapper
Accettazione
Importazione
PM
Generazione
Ricevute
Audit /
Monitoring
Pubblicazione /
Denorm.
Fornitura
Trattamento
Deleghe
Desktop
Application

21. Forniture Massive - PM
PM IAmStartedBy<FornituraDiImportazioneRegistrataEvent>
Fornitore FTP Ricezione PM Mapper Accettazione Importazione Pubblicazione Gen. Ric
Carica
File
Polling FornituraRegistrata
Subscribe
FornituraRegistrata
Subscribe
FornituraMappata
Subscribe
ContrattoValidato
Subscribe
FornituraImportata
Subscribe
FornituraPubblicata
MappaFornitura
For. Mappata
ValidaContratto
ContrattoValidato
ImportaFornitura
FornituraImportata
PubblicaFornitura
FornituraPubblicata
GeneraRicevuta
RicevutaGenerata

22. Contratti
• Il vero core
– Tutti i contesti vogliono sapere qualcosa dei
contratti.
– Ai contratti c’è attaccato il pricing, quindi è qui che
gli diciamo come contare i soldi che facciamo o che
faremo 

23. Contratti

24. Contratti
• Requisiti
• Possibilità per gli account manager di registrare
contratti dall’esterno
• Mi interessa sapere lo stato del mio contratto nel
tempo e poter eventualmente fare previsioni su quale
sarà o sarebbe potuto essere lo stato del mio sistema
se l’account manager avesse fatto scelte differenti
• Presente all’inizio e di recente eliminato

25. Contratti – Le nostre scelte
• Applicazione web («classico» html/angular/web
api)
– Di recente abbiamo switchato su sola
autenticazione Windows perché il requisito è
cambiato
• ES implementato usando NEventStore (forkato)

26. Contratti
WebApp
Web API
Aggregato
BusPulser «ContrattiPM»
ProjectionsEventStore
Repository
ReadModel
Altri contesti

27. Produzione
• Facile o difficile?
Questione di punti
di vista.
– Stress test
– Penetration test
– Metriche
– Scaling

28. Domande?

29. Link-o-grafia
• http://ziobrando.blogspot.it/search/label/EventSt
orming
• http://martinfowler.com/articles/microservices.ht
ml
• http://Commitstrip.com
• https://github.com/rebus-org/Rebus
• https://github.com/NEventStore/NEventStore