Può risultare utile usare OpenAPI o simili per avere le interfacce dei vari servizi e uno stub per il codice autogenerato.

A partire dai file in docs/openapi realizzare i file di configurazione per openapi-generator-cli.

Definire la struttura della relazione man mano che si procede con il progetto

I processi di ACMESky devono essere ben dettagliati, mentre i ruoli esterni possono essere modellati come collapsed pools. Anche le successive implementazioni non serve che siano ben dettagliate ma solo nel dettaglio che serve per far funzionare la coreografia.

Da documentare non a basso livello: non sappiamo infatti né gli input né gli output.
Raccontare più o meno come vengono contattati le varie interfacce e come vengono sfruttate le capability per realizzare i processi di business.
Quindi di fatto si può prendere spunto dalla sezione BPMN, ma andando un po' più in dettaglio perché si sta comunque avendo a che fare con metodi.

Assunzioni che vengono fatte per tenere il progetto semplice:

• Le offerte che vengono presentate agli utenti sono solo relative a una sola compagnia aerea, cioè l'utente acquisterà una coppia di voli DIRETTI, della stessa compagnia, sia per l'andata che per il ritorno
• l'acquisto dell'offerta presso la compagnia aerea non può generare errori (infatti nel BPMN non sono considerati), anche perché quando viene inviata l'offerta all'utente e partono le 24h entro cui può accettarla i voli sono bloccati per lui
• l'acquisto del transfer da casa ad aeroporto e viceversa non può dare errori, ovvero la compagnia di trasporto sarà sempre disponibile per l'ora, il luogo e la data richiesta dall'utente
• una volta che l'utente inizia il processo di acquisto offerta il codice viene bloccato (ovvero se due utenti hanno lo stesso codice, il secondo non può utilizzarlo) fino a che il processo di acquisto fallisce (e allora viene ripristinato il codice e il secondo utente può usarlo)
• i voli sono tutti diretti
• i dati di pagamento dell'utente vengono sottoposti a type-checking e il codice della carta di credito viene verificato attraverso la Formula di Luhn
• le RESTful API ritornano solo codici 200 se è andato tutto bene, 400 per dichiarare errori sintattici (dati errati nella richiesta) e semantici (dati corretti nella richiesta ma non sensati, e.g. codice di carta di credito non esistente o importo errato)
• il servizio di calcolo delle distanze geografiche ritorna il valore della distanza secondo la Formula di Haversine, che calcola la distanza di due punti sulla superficie di una sfera e, essendo invece la terra un geoide, non è completamente corretto.
• nel processo di Acquisto Offerta da parte degli utenti, dopo che ACMESky ha richiesto al Payment Provider di far pagare l'utente e l'utente ha pagato, il Payment Provider sa già quale endpoint di ACMESky contattare per mandare l'esito del pagamento (può benissimo essere stato fatto al momento in cui ACMESky si è registrato al payment provider). L'alternativa sarebbe mettere lo stesso endpoint nella richiesta POST /payments/request di Payment Provider.

TinySOA è un profilo per Papyrus. Guardare su Virtuale.