In questo breve articolo Public versus Published Interfacce del 2002, Martin Fowler distingue tra "interfacce pubbliche" facilmente mutevoli e più difficili da cambiare "interfacce pubblicate":
The key difference is being able to find and change the code that uses an interface. For a published interface, this isn’t possible, so you need a more elaborate interface update process.
Indietro dei suoi consigli sulla pubblicazione inclusi:
- Non trattare le interfacce come pubblicate a meno che non siano
- Non pubblicare interfacce all'interno di un team
- Pubblica il meno possibile il più tardi possibile
L'articolo è stato scritto nel 2002 prima che le architetture basate su microservizi diventassero popolari. Nella mia azienda, ci stiamo spostando verso i microservizi e stiamo anche preparando il passaggio da un edificio dal modello sorgente al controllo delle versioni. L'ipotesi è che sia più semplice supportare lo sviluppo in un'organizzazione con un numero crescente di sviluppatori, poiché il controllo delle versioni consente un maggiore controllo su quando si desidera applicare le modifiche al codice, poiché è necessario aumentare attivamente la versione della libreria da cui si dipende .
Quando leggo ora l'articolo di Martin Fowler, trovo i suoi argomenti molto convincenti. D'altro canto, le architetture dei microservizi e anche il controllo delle versioni interno sembrano essere tendenze che portano a più interfacce pubblicate.
Devo ammettere che non ho esperienza con i microservizi. Quando si parla di versioning interno, non mi aspetto molta esperienza per alcuni progetti Javascript più piccoli in cui abbiamo diviso il nostro codice in piccoli progetti e utilizzato npm per gestire le dipendenze. La maggior parte del mio tempo, ho lavorato a progetti Java medio-grandi in cui si costruisce dalla fonte e che aveva per lo più un'architettura monolite. Aspettatevi la comunicazione RMI tra i componenti, la maggior parte delle interfacce potrebbe essere classificata come pubblica (non pubblicata).
Forse mi manca qualcosa, ma vedo alcuni obiettivi contrastanti nelle ultime tendenze e l'articolo di Martin Fowler di 14 anni fa. Ad esempio, "Non pubblicare interfacce all'interno di un team" sembra essere in conflitto con la tendenza che ogni team cerca di suddividere il suo progetto in molti piccoli servizi indipendenti con un'interfaccia "pubblicata" ben definita. Anche l'introduzione della versione semantica di tutte le librerie e dei piccoli progetti API sembra essere una violazione di tale consiglio e rende più difficile il refactoring.
Sono un po 'confuso, quindi volevo chiarire in quali condizioni pubblicare un'interfaccia ha più vantaggi che evitarlo a tutti i costi. Ecco la mia comprensione di entrambe le parti, correggimi se ho sbagliato.
In breve l'argomento di Martin Fowler:
- Evita le interfacce pubblicate perché impedisce il refactoring
Argomento microservice:
- Dividi il tuo sistema in piccoli servizi con un'interfaccia ben definita, in quanto è più facile da capire.
- Invece di refactoring un monolite, tutti i servizi sono così piccoli che possono essere facilmente comunque
L'altro argomento "build from source" vs version management non viene toccato nell'articolo e non è strettamente necessario nelle architetture dei microservizi, ma volevo comunque menzionarlo perché vedo un simile compromesso:
- Avere accesso a tutto il codice sorgente consente un più facile refactoring al costo di dover lavorare con più codice; le modifiche ad alcune librerie diventano immediatamente visibili ai progetti dipendenti (che possono essere un vantaggio o uno svantaggio)
- La gestione delle versioni interne consente di eseguire il checkout solo del codice necessario ma rende più difficile il refactoring a meno che gli sviluppatori non abbiano una grande disciplina nell'aggiornare le loro dipendenze regolarmente (altrimenti, le interfacce pubbliche diventano "pubblicate" in modo simile all'esempio strong di proprietà del codice nell'articolo ).
- Se alcuni progetti non vogliono aggiornare il loro codice, puoi comunque eseguire dei refactoring non retrocompatibili, ma in seguito avrai un lavoro aggiuntivo quando infine aggiornerai gli altri progetti.
La mia conclusione attuale è che la tendenza è incoraggiare le interfacce di pubblicazione al fine di separare i servizi il più possibile. In altre parole, la raccomandazione nell'articolo per lo più non si applica più alle odierne architetture di sistema preferite. Si applica ancora all'implementazione di un microservizio internamente, ma quando sono abbastanza piccoli non rimangono troppe interfacce non pubblicate. Quindi il consiglio era più pertinente nel 2002, dove i monoliti erano più comuni.
Saresti d'accordo? (Disclaimer: Come ho detto, sono abbastanza un novizio su questo argomento.)