Bene, per quanto ho capito, hai già la tua risposta.
Sostituisci "codice comune" con "regole aziendali comuni" e diventa ovvio. Se i comportamenti di entrambi i servizi A e B sono cambiati, devi ridistribuire sia A che B.
Tuttavia , penso che questa situazione odori familiare ... hai "codice comune" per cose che non sono regole aziendali veramente comuni? Se lo fai, ti aspetta qualche sorpresa.
Potrei semplicemente allontanarmi dall'argomento qui, ma l'ho già visto prima. Molto spesso le persone vedono due blocchi di codice simili e pensano "Ehi, l'ho già visto prima ... Un ciclo for a una raccolta di ordini, filtrati da IsSmitted ... Sì, proprio come in quell'altro componente. penso di poterlo estrapolare in un oggetto comune! ". Questo è presto seguito da un "Ehi ragazzi, guarda, ho appena rimosso alcune duplicazioni!" (Potrei o non potrei citarmi qui ...).
Quello che succede dopo è sorprendente: un componente cambia quel comportamento, mentre l'altro no. Quindi vai al "componente comune" e prova a suddividere in "pezzi riutilizzabili" più piccoli, cercando di mantenerlo come comune, ma diverso per ogni componente dipendente. Succede per un po ', finché la gente non si rende finalmente conto che il codice non dovrebbe davvero appartenere a questo.
Risulta che questo è spesso il risultato del seguire DRY e "rimuovere la duplicazione", senza considerare che, in un livello più astratto, non c'è davvero una duplicazione nei due blocchi di codice molto simili. Ora, non sto dicendo ASCIUTARE e "rimuovere la duplicazione" è un male, ma devi anche prestare attenzione al Principio di Responsabilità Unica.
A volte, due blocchi identici di codice svolgono ruoli diversi nel sistema e capita per caso di fare la stessa cosa. Ma poiché i ruoli sono diversi, i requisiti per un ruolo possono cambiare mentre l'altro no. Raccomando di guardare questo talk sull'SRP , dove viene fornito lo stesso esempio.
Potrebbe sembrare che mi sia allontanato troppo dall'argomento qui, ma SRP è strettamente correlato alla consegna continua, esattamente perché mira a ridurre la quantità di accoppiamento accidentale tra moduli (e servizi), permettendo modifiche a essere mantenuto ad un intervallo minimo di impatto, fino al punto in cui deve essere ridistribuito solo un modulo.
Ma hey, potrei davvero essermi allontanato e hai davvero un comportamento commerciale comune tra i tuoi servizi. Se è così, come ho detto prima, hai già la tua risposta. Tutto ciò che cambia viene ridistribuito e non dovrai trovare nuovi strumenti per questo, poiché questo dovrebbe essere ovvio, perché devi anche testare questi servizi.