Mi sono allontanato da un progetto per alcune settimane. Prima di lasciare l'organizzazione stava discutendo un modello architettonico per i nostri microservizi. In genere, un'istanza svolge due ruoli nella nostra organizzazione.
- Riceve richieste RESTful e le elabora di conseguenza
- Funziona come un processore batch, leggendo grandi quantità di dati e elaborandoli.
Andando avanti probabilmente vorremmo separare l'elaborazione in batch dalla gestione REST. La questione del modo migliore per separare queste preoccupazioni era in discussione. Una delle nostre proposte era di configurare il nostro processo di implementazione build in modo che un'istanza potesse essere distribuita in modalità web o in modalità caricamento dati. Mi è piaciuto in particolare questo approccio perché il bilanciamento del carico sarebbe stato facilitato con questo approccio in quanto è stato possibile aumentare o diminuire il numero di istanze in base alla quantità di lavoro disponibile per un'attività specifica del contesto.
Tuttavia, al mio ritorno ho scoperto che era stato definito un paradigma diverso: vogliono creare due repository di codice sorgente aggiuntivi per un totale di 3 progetti:
- Un progetto comune che contiene tutta la logica a livello di servizio e deposito, oltre agli oggetti dominio.
- Un progetto web che fa riferimento a common per gestire il traffico REST
- Un progetto dataloader che fa riferimento a common per gestire attività ad alta intensità di dati
Non sono davvero un fan di questo approccio. Per prima cosa, tutti i nostri test di integrazione sono ora nel progetto web e stiamo davvero testando la logica al n.1 (possiamo fare una revisione dei nostri test per favorire l'integrazione / test unitari a livello comune, ma ci vorrà tempo e sudore ). Il ciclo di debug / sviluppo è davvero scomodo in quanto gli errori rilevati in 2 o 3 richiedono di tornare indietro a 1 per apportare modifiche, aggiornare la dipendenza di esperti e tornare ai test. Lavorare con queste dipendenze incluse è davvero un problema in generale.
È fattibile, ma richiede più tempo. Mi ha davvero fatto pensare al concetto di esperienza degli sviluppatori . Non penso che ne parli, ma penso che sia importante tanto quanto l'esperienza dell'utente. Soprattutto perché questo è un progetto che ha un ciclo di sviluppo aggressivo. Lo sviluppo sul ramo in cui viene implementato è davvero ingombrante e ... noioso!
I motivi della gestione per favorire questo approccio non sembrano adattarsi al disagio. Alcuni argomenti che ho sentito è che il codebase sarà troppo grande senza questa separazione. Sto anche sentendo che potrebbero voler distribuire una versione della libreria comune per i dati e una diversa per il web (non riesco a immaginare un caso d'uso valido per questa richiesta).
Mi chiedo se qualcun altro ha esposizione a questo stile architettonico che, a mio parere, sembra un anti-modello. Sono prevenuto contro un approccio valido? Presto mi rivolgerò alla direzione per raccomandare di tornare a una base di codice singolo ma organizzandola come un progetto a più moduli (3 file di build, distribuibili in base al contesto).