I microservizi interrompono il contesto limitato?

Question

Sono un po 'confuso. Sto lavorando in una giovane società bancaria e abbiamo deciso di implementare un'architettura DDD per rompere la complessità.

Quindi, ecco la mia domanda (segue una proposta di design fatta da qualcuno nel team). Diciamo che abbiamo 3 diversi domini. D1, D2, D3, che espongono servizi di dominio (web). Ogni dominio manipola entità aziendali fortemente tipizzate, che si basano sulle stesse tabelle. Di fronte a questi domini, vogliamo un microservizio per garantire che i dati presenti nelle tabelle siano coerenti, in maniera centralizzata. D1, D2 e ​​D3 chiedono al microservice di mantenere i dati conformi a regole specifiche. Vogliamo che il microservizio funga da proxy CRUD per le tabelle. Il microservice fornisce specifici DTO ai domini D1, D2 e ​​D3, offuscando le tabelle a D1, D2, D3.

Questo approccio sembra buono? Prenderesti in considerazione l'utilizzo dei microservizi in un'architettura DDD per gestire CRUD e la coerenza dei dati per 1+ domini? Il "CRUDing" e la convalida dei dati con un microservice interrompono il contesto limitato? Quali sono le migliori pratiche con i microservizi in un'architettura DDD, se ce ne sono?

Molte grazie per il vostro contributo,

[EDIT]

Il seguente articolo mi hanno aiutato a perfezionare il mio pensiero: http://martinfowler.com/bliki/MicroservicePremium.html

Microservices sono utili in situazioni complesse in cui i sistemi monolitici fallito di essere gestibile. Non sono buoni candidati per implementazioni di design in anticipo. D'altra parte, DDD cerca di affrontare la complessità all'inizio dei progetti. Il DDD riuscito non dovrebbe soddisfare le implementazioni dei microservizi.

Answer 1

Cose come la convalida, il calcolo e la persistenza (CRUD) sono tutte funzioni e non servizi. Centralizzando queste attività in un unico servizio si stanno strettamente accorpando tutti gli altri servizi ad esso, e si perde il vantaggio principale di SOA. Rendere i vostri servizi liberamente accoppiati pur mantenendo un'elevata coesione dovrebbe essere il vostro obiettivo primario. Sento che questo design viola questo.

Si desidera progettare i servizi come sezioni verticali di funzioni aziendali correlate, piuttosto che con servizi e livelli generici centralizzati. Un servizio dovrebbe essere composto da componenti distribuiti in tutta l'azienda dal database fino all'interfaccia utente. Inoltre, ogni servizio dovrebbe avere il proprio database o almeno lo schema se questo non è pratico. Non appena disponi di servizi che condividono un database, ti ritrovi di nuovo strettamente associato.

In una nota finale, se uno dei tuoi servizi deve fare un semplice inserto CRUD, allora è tutto quello che dovrebbe essere. Non è necessario prima mapparlo a un modello di dominio. Salva DDD per i processi aziendali che hanno invarianti reali che devono essere applicati. Non deve essere un approccio tutto o niente. Usa lo strumento che ha senso per ogni caso d'uso.

Answer 2

I microservizi non devono "interrompere" i contesti limitati, sono complementari poiché c'è un natural correlation between microservice and BC boundaries.

vogliamo un Microservice a prestigiose che i dati persistevano nelle tabelle è coerente, in modo centralizzato

Microservices non sono qui per scopi facading. E sono tutti su de centralizzazione, non centralizzazione. Sono unità modulari organizzate attorno a capacità di business.Solitamente fungono da gateway per i contesti limitati, di fronte al dominio, non da proxy a un archivio persistente dietro il dominio.

Sembra che tu stia cercando di applicare la soluzione sbagliata al tuo problema - usando microservizi come punti di convergenza a un monolite data-centrico, che sconfigge il loro intero scopo.

Forse dovresti approfondire ciò che intendi per "garantire che i dati siano permanenti coerenti" e "mantenere i dati conformi a regole specifiche". Potrebbe essere implementato solo nel livello di persistenza o in servizi che non sono microservizi.