Qual è una buona ragione per separare intelligenza e strati dao in un microservizio?

Question

Qual è una buona ragione per separare intelligenza e strati dao in un microservizio?

#1 da (5 voti)
#2 da (3 voti)

6

Sto avendo un dibattito a lungo termine con il mio architetto sulle scelte di architettura. L'impresa in cui lavoro è migrare da un'architettura monolitica a una microservizi.

Il dibattito si basa sul buon approccio per la gestione dell'accesso ai database. Uno di noi è fermo, non c'è bisogno di separare DAO e servizio (l'accesso al database viene gestito direttamente dalla classe di servizio) e l'altro è contrario.

Ne discutiamo da giorni, e non riesco a trovare una buona ragione per convincerlo, e non può neanche convincermi.

La domanda è in realtà molto semplice: in un microservizio atomico REST (un microservizio che gestisce solo un metodo REST), dovremmo avere una classe DAO separata o no? Quali argomenti potresti fornire per separare o mantenere tutto insieme?

Questo è un progetto orientato all'OOP (Java), se è importante.

microservices layers service dao

posta Rémi Doolaeghe 28.10.2016 - 15:34

fonte

2 risposte

Leggi altre domande sui tag microservices layers service dao

Come faccio a tenere traccia delle richieste di modifica dell'interfaccia utente minuscole / piccole in Agile? Le migliori pratiche per ottenere l'ultimo record inserito nel DB

score 5 · Answer 1

Non devi discuterne per "giorni". In quel lasso di tempo, puoi effettivamente implementare un microservizio delle dimensioni che stai descrivendo in entrambi i modi e confrontare per te stesso. Guarda come è facile leggere il codice. Guarda come è facile scrivere test unitari e test di integrazione. Valuta onestamente l'accoppiamento e la coesione del codice.

Posso risparmiarti un po 'di tempo, però. Talvolta il nostro team eredita la proprietà di servizi che non separano le responsabilità in modo appropriato e sono sempre stati fragili, soggetti a errori e difficili da testare. Quando abbiamo bisogno di fare il nostro primo cambiamento dopo essere diventati proprietari, abbiamo scoperto che è più veloce e più sicuro pianificare la separazione dei livelli prima di apportare la modifica.

I microservizi forniscono dei begli confini esterni, ma ciò non significa che tu elimini i normali principi di progettazione all'interno del servizio.

score 3 · Answer 2

Non c'è motivo per cui più micro servizi non possano condividere una libreria di base comune che contiene (rullo di tamburi, per favore) tutte le classi di accesso ai dati comuni! Quindi il tuo micro servizio è libero di scegliere quali classi di DAO / repository di cui ha bisogno. Forse hai bisogno di più repository o oggetti di accesso ai dati in un unico servizio micro.

Il motivo per separarli si riduce al Principio della singola responsabilità: una classe dovrebbe avere solo una ragione per cambiare.

Non appena si inizia a incorporare la logica di accesso ai dati in un'applicazione, si introduce il rischio che tale logica venga copiata e incollata in un'altra applicazione che consenta la duplicazione del codice di introdursi nell'ecosistema. Un micro servizio dovrebbe essere atomico nella funzione che serve. Non deve essere atomico nel codice che contiene.

Da Martin Fowler :

...the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process...

These services are built around business capabilities and independently deployable by fully automated deployment machinery.

Si noti che non menziona nulla su come si dovrebbero progettare i componenti di accesso ai dati e si concentra invece sulla funzione per cui è costruito il servizio.