Architettura dei microservizi e contesti limitati

Credo che la tua domanda sia un errore di categoria . In breve, i microservizi sono un modo di organizzare la tua architettura, mentre i contesti limitati sono un modo di organizzare le classi / oggetti che manipoli nel codice. Potrebbe esserci una correlazione uno-a-uno tra i due, o potrebbe non esserci. Non c'è certamente alcuna connessione necessaria tra i concetti.

Se posso prendere a prestito l'esempio di contesti limitati di Martin Fowler:

In questo caso, i contesti limitati ci dicono semplicemente che abbiamo bisogno di una classe di prodotto diversa nel contesto di vendita rispetto a quanto facciamo nel contesto di supporto. Questo non ci dice dove o come queste classi dovrebbero essere archiviate o recuperate. Ad esempio:

• Questo può essere implementato senza microservizi. Se si tratta di una semplice applicazione rich client che non parla mai su Internet, ovviamente i microservizi non hanno molto senso.

• Puoi implementarlo con un microservizio per contesto. Forse i contesti di vendita e supporto sono rappresentati ciascuno da un singolo database e ogni database ha un singolo microservizio. Quindi parleresti con il microservizio di vendita per ottenere il tuo prodotto di vendita e il microservizio di supporto per ottenere il tuo prodotto di supporto.

• In alternativa, puoi implementarlo con un microservizio per tipo di oggetto. Potrebbe esserci un database di prodotti che memorizza sia le informazioni di vendita e di supporto, sia il microservice per l'una o l'altra versione del Prodotto. O forse lo chiedi solo per un blob di informazioni e l'utilizzo di quel blob per creare un'istanza di un SupportProduct rispetto a un SalesProduct viene svolto altrove.

Microservices can be thought just as a particular way of applying the idea of bounded contexts from DDD?

Il modo in cui stai ponendo la domanda che stai implicando una strong relazione tra microservizi e contesti limitati. Quello che è un equivoco (ma forse non è quello che volevi dire, solo come le parole sono uscite).

Direi piuttosto che i microservizi potrebbero essere adatti per implementare il contesto limitato se si implementa DDD.

Ricorda, non tutti i progetti utilizzano DDD (e la maggior parte di essi lo fa, correttamente non lo fa comunque in modo appropriato). In questi casi i microservizi possono essere applicabili.

Contesti e microservizi limitati sono simili ma (dalla mia comprensione) un Contesto Limitato può essere costituito da diversi Microservizi. Dalla descrizione di Martin Fowler del Contesto Limitato, ogni rettangolo nei contesti limitati della sua illustrazione potrebbe essere un Microservizio, quindi tu? ne possiamo avere uno per i biglietti, uno per i difetti, ecc. O molti di questi servizi potrebbero essere combinati in un microservizio più ampio, fino a un microservizio per l'intero contesto limitato.

Microservices can be thought just as a particular way of applying the idea of bounded contexts from DDD?

Sono d'accordo, anche se lo farei in un modo diverso, più come Pete.

Contesto limitato è solo un'area arbitraria con qualche confine tangibile, o recinto. Quando vengono implementati con microservizi, questo limite coincide con il limite del processo (che è, nel caso, un indicatore scarso di (micro-) confine del servizio ). Puoi venire con il tuo tipo di confine. Ad esempio, può essere una directory di progetto di livello superiore, qualcosa che è più di alto livello rispetto ai moduli. Ad ogni modo, questa è solo una prospettiva "in fase di esecuzione" per esaminare il concetto di Contesto limitato.

Supponiamo che l'esperto di dominio non sappia cos'è un microservizio. Contesto limitato per lui o lei è solo una rappresentazione visiva su una lavagna, dove termini specifici hanno senso, certa funzionalità risiede e si applica il proprio linguaggio ubiquo.

Infine, capire come decomporre il dominio e definire contesti limitati è un passaggio fondamentale che non vuoi rovinare, poiché influisce strongmente sull'intero ciclo di vita di un sistema.