Lascia che ti spieghi cosa intendo per località e ripetizione. Il ritaglio corrente di strumenti di gestione della configurazione disgiunge la configurazione da tutto il resto anche quando è un po 'dannoso farlo. Un caso in cui è dannoso è nella configurazione dell'applicazione. Credo che la configurazione dell'applicazione debba risiedere nello stesso repository dell'applicazione stessa anziché in qualche altro repository o in un libro di cucina o in un modulo fantoccio. Meglio ancora l'attuale libro di cucina o il modulo fantoccio dovrebbero essere affiancati all'applicazione e il sistema di compilazione può capire come impacchettare il tutto in modo che il meccanismo di distribuzione possa essere il più semplice possibile.
Un problema con questo set up è che può portare a molte ripetizioni perché molti pacchetti useranno simili o addirittura esattamente gli stessi libri di cucina e burattini degli chef, ma invece di trovarsi in una posizione centrale questi libri di cucina e moduli sono ora duplicato in ogni repository dell'applicazione. La cosa istintiva da fare in questo caso è di scomporre la comunanza e metterla nel proprio repository, ma penso che ciò non sia corretto perché introduce la non-località. Ora per capire come funziona l'applicazione lungo tutto il suo ciclo di vita devi inseguire le dipendenze in qualche altro posto e, a volte, non è chiaro dove questo altro posto sia dovuto alla separazione tra operazioni e sviluppo del prodotto.
Quindi qual è il trade-off corretto qui? Penso che la non località renda le cose più magiche di quanto debbano essere e far rispettare la località porta a ripetizioni inutili.