Architettura dello strumento di gestione per molteplici API di back-end e concetti comuni tra di loro

1

Attualmente sto sviluppando la prima di molte API di backend diverse. In qualche misura condivideranno alcuni concetti comuni (informazioni personali, informazioni sui tribunali, ecc.); anche se tra di loro ci sono anche molte differenze. Ad esempio, uno sarà per determinate multe, altri per i biglietti più veloci, altri più legati ai contratti.

Ho anche costruito la prima versione di uno strumento per occuparmi dell'amministrazione di questi. L'amministrazione avviene sul database utilizzato dal progetto, non su qualche tipo di API offerta dall'API del progetto.

Ho creato una libreria comune per le classi di DTO, Entità ed Entity Repository condivisa dall'API di back-end e dallo strumento amministrativo, ma questo sicuramente non sembra il modo corretto di lavorare. Mi sembra che sarebbe meglio che lo strumento amministrativo gestisca l'applicazione tramite un'API offerta. Mi sembra che usare qualcosa come REST sia piuttosto fragile, e il mio codice sembra semplicemente più "solido" in questo momento. Suppongo semplicemente che la roba diventerebbe più fragile se aggiungo altre API di back-end all'equazione, comunque.

Mi è anche venuto in mente che potrei forse creare più librerie condivise e che quelle potrebbero essere collegate a livello di dominio. Ciò significherebbe che il mio strumento amministrativo avrebbe tutte le diverse librerie importate e le API di back-end di cui hanno bisogno la conoscenza del dominio. Il biglietto per eccesso di velocità e le multe avrebbero "Persone" e "Multe" come librerie, i contratti avrebbero cose come "Persone", "Abitazioni", "Occupazione", ecc.

Quali sono i principali difetti di questi progetti e come gestirli al meglio? I microservizi sono tutti "caldi" in questo momento, ma credo che le mie API di back-end non comunichino realmente tra loro, ma condividono concetti simili.

Nota che anche se al momento non abbiamo il concetto di utenti (tutte le azioni che si verificano sono vincolate a un "uso singolo"), questo potrebbe cambiare in seguito.

Attualmente sto costruendo le applicazioni in Spring (Spring Data, REST API per i frontend realizzati in AngularJS) e anche se attualmente non sto usando Spring Integration, mi sembra che possa aiutare con l'integrazione degli strumenti di amministrazione con il back-end .

    
posta Kristof 03.07.2015 - 08:09
fonte

0 risposte

Leggi altre domande sui tag