Non c'è niente di sbagliato nell'avere lo stesso codice in esecuzione in due diversi contesti. Non prenderei nemmeno in considerazione questo codice duplicato. Quello che considero il codice duplicato è se il codice sorgente è biforcuto e ora abbiamo un codice molto simile ma potenzialmente diverso o divergente che viene mantenuto separatamente e, questo è un problema che può continuare a peggiorare nel tempo.
Ora, come dici tu
changes have to be made in two places
Questo indica che hai fonti bifronte ed è effettivamente duplicato. Definirei due repository diversi, entrambi modificabili, ma con lo stesso codice sorgente duplicato di una situazione indesiderabile.
Quindi, hai diverse scelte:
- condividi il codice sorgente direttamente da un singolo repository comune
- crea una libreria condivisa
- crea un micro servizio
Personalmente, preferisco l'approccio (1) per molte situazioni, per la sua semplicità, se puoi far sì che tutte le parti siano d'accordo a reperire almeno quell'insieme di classi da un repository comune, e puoi fare una versione di tutti i client che consumano insieme quando i cambiamenti incompatibili si verificano in quel codice.
Suppongo che tu possa usare anche più repository purché tu ne definisca esattamente uno come fonte di verità, e l'altro non debba mai essere modificato dagli umani (fornirei un po 'di automazione per copiare i sorgenti come parte di build).
Successivamente, preferisco l'approccio (3) in un ambiente di micro-servizi. Un micro servizio condiviso può estrapolare i clienti da determinati dettagli e consentire una manutenzione indipendente di tale servizio dagli altri client, offrendo un accoppiamento più flessibile.
Infine, preferisco l'approccio alla libreria condivisa. Ha problemi di versioning simili al codice sorgente condiviso con alcuni problemi aggiuntivi di build, test e packaging; anche se a suo favore può offrire un certo formalismo delle tue classi come API.