Esporre funzionalita gia operative via API senza duplicare business logic e mantenendo parita di stati, vincoli, documenti e permessi.
Cosa e stato studiato
Sono stati studiati flussi web gia operativi, prodotti assicurativi, documenti, export, stati e permessi. Il punto critico era esporre integrazioni API senza creare una seconda logica parallela rispetto al backoffice.
Cosa e stato fatto
ComeToWeb e intervenuta su un perimetro preciso: layer API V1, documentazione OpenAPI, parita Web/API, fix documentali, export AXA Persona+ e QA tecnico. Il lavoro non sostituisce la piattaforma originaria, ma ne stabilizza ed evolve parti misurabili.
Come e stato fatto
La base e Laravel/PHP con database relazionale, viste PDF, comandi/export e documentazione tecnica. Il metodo applicato e stato leggere il comportamento esistente, riusare business logic dove possibile, limitare il cambiamento e chiudere ogni intervento con prove e tracciabilita documentale.
Architettura e tecnologie
Come lo stack e stato usato nel progetto
Backoffice esistente come sorgente di verita
Il backoffice contiene regole, stati e vincoli gia usati dagli operatori. L'API deve rispettare quel comportamento, non reinventarlo. Questa impostazione riduce il rischio di divergenze tra cio che vede l'operatore e cio che consuma un sistema esterno.
Layer API e OpenAPI
Il layer API V1 viene documentato e trattato come superficie controllata. OpenAPI aiuta a esplicitare contratti, input, output e limiti, rendendo piu semplice integrare portali esterni senza lasciare ambiguita operative.
Documenti ed export regolati
PDF assicurativi ed export AXA sono aree critiche perche traducono dati di polizza in documenti e tracciati. Qui non basta che la pagina funzioni: date, importi, flag, periodi di competenza e formati devono restare coerenti con il dominio.
Perimetro ComeToWeb su prodotto esistente
Il progetto va raccontato come interventi su una piattaforma esistente: API, documenti, export, QA e tracciabilita. Questa precisione e importante per essere corretti verso il prodotto originario e chiari verso il cliente che cerca manutenzione evolutiva.
Pattern implementativi
Dettagli tecnici che hanno guidato le scelte
Riuso della business logic
Quando una funzione esiste gia nel web, l'API deve evitare duplicazioni fragili. Il lavoro tecnico consiste nel cercare il punto corretto in cui agganciarsi, riusare regole e validazioni, e aggiungere solo il layer necessario all'integrazione.
Gate anti-divergenza
Parita Web/API significa definire controlli contro differenze silenziose: stati non allineati, permessi diversi, documenti generati con dati discordanti o export che includono record sbagliati. I test mirati servono a intercettare proprio queste divergenze.
Fix circoscritti su documenti ed export
Welcome Letter ed export AXA richiedono interventi chirurgici: individuare campo, data o flag corretto, modificare solo il ramo interessato e verificare che formato, scheduler e flussi correlati restino stabili.
QA e documentazione di chiusura
Ogni intervento viene chiuso con evidenza: documenti ARC, MASTER_QA, comandi di verifica o riferimenti al file modificato. In un dominio regolato, questa tracciabilita vale quanto il codice per capire cosa e stato cambiato e perche.
Risultati e apprendimenti
Interventi evolutivi tracciati su piattaforma assicurativa esistente, con API, documentale, export AXA e QA allineati al comportamento operativo.
- su prodotti esistenti il primo valore e non duplicare logiche
- API e web devono restare pari nei comportamenti critici
- documenti ed export richiedono prove piu specifiche delle normali CRUD