Oltre alla risposta di Arseni (che sono d'accordo)
È davvero difficile determinare quanto piccolo deve essere un Microservices e molte volte le linee dei contesti limitati sono sfocate.
Più leggo su Microservices e più pratico, più sono convinto che È richiesta una profonda comprensione del dominio che stiamo modellando e dell'organizzazione della società che viene riflessa .
Forse, ti sei precipitato prematuramente nella progettazione dei servizi. Probabilmente, il tuo capo vede i bisogni / obiettivi da un altro punto di vista. È chiaro che hai bisogno di consenso. Il consenso è raggiunto quando tutti i punti di vista sono allineati con gli obiettivi e le esigenze dell'organizzazione (il nostro o il cliente "per cui lavoriamo).
Non so qual è il tuo ruolo nel progetto, ma se sei un tecnico (come sono io), determinare i contesti limitati è lontano dall'essere una decizione tecnica. Ciò non significa che tu non abbia nulla da dire. Siamo un po 'uno "strumento". Siamo lo strumento che meglio serve una proposta specifica e fornisce una guida. Realizziamo la visione del business proiettando la visione tecnica su quella aziendale. Ma entrambe le visioni devono essere allineate ed equilibrate.
D'altra parte, quando pensiamo in Microservices, tendiamo a identificare i servizi con le caratteristiche del dominio. Trasformiamo le diverse funzionalità dell'applicazione in servizi.
Tuttavia, spesso dimentichiamo che i microservizi sono sistemi indipendenti (di per sé) piuttosto che "semplici caratteristiche". Quindi, cosa ci impedisce di determinare i limiti all'interno di un dato servizio? Cosa ci impedisce di dividere un microservizio in due o più microservizi annidati? O viceversa, perché le funzionalità correlate non possono essere raccolte in un singolo Microservice?
Ciò che conta è la coesione che fornisce al sistema globale.
Gli altri microservizi non hanno bisogno di conoscere gli interni né i dettagli di protesi del resto. L'interfaccia per la collaborazione è tutto ciò che hanno bisogno di sapere sugli altri.
Ad esempio, quando il tuo capo ha suggerito diversi microservizi per ogni possibile tipo di pagamento, non stava andando oltre.
Il processo di pagamento è abbastanza importante da meritare un microservizio. La sua complessità può anche portarci a determinare che i microservizi nidificati possono fornirci la flessibilità che richiede un mercato globale. E, naturalmente, renderà più facile aggiungere nuovi tipi di pagamento, per distribuirli senza il rischio di introdurre bug in quelli esistenti. Inoltre facilita il test e il monitoraggio.
Ad esempio, nel mercato di oggi (quello globale), le applicazioni sono esposte a diverse regolarizzazioni del mercato locale e leggi in cui alcuni tipi di pagamento potrebbero non essere consentiti a spese di altri tipi.
Riassumendo, prima di formulare le tue ipotesi su come dovrebbe essere il sistema e pensare in termini di hai ragione / torto , siediti con tutti gli stakeholder al fine di raggiungere il consenso. Consenso nel senso che parti interessate tecniche e non tecniche condividono la visione strategica (cosa fare) e la tecnica (come fare).
is my boss right?
Quando devo progettare un nuovo sistema, devo ricordare a me stesso uno dei motivi più difficili che ho imparato in questo lavoro:
- La creazione di un decennio unilaterale spesso mi porta a conseguenze terribili a causa di ipotesi errate.
Né tu né il tuo capo avete torto o ragione. Entrambi non condividete la stessa visione. Ricorda che nella tecnologia del software non ci sono regole d'oro, né regole fisse inamovibili. Solo convenzioni e buone intenzioni.
Resta flessibile e scettico sul significato di tutto ciò che leggi là fuori. Fai molta attenzione con frasi come: ha senso , buon senso , ecc. Ciò che per te ha senso può o non può avere senso. E non esiste il buon senso