Secondo me il problema è tutto li e ruota attorno all’uso del singolare e il problema siamo sempre noi sviluppatori. Abbiamo parlato di bene e male ci siamo lasciati con una domanda, poco tempo fa abbiamo invece dettagliato che cosa sia un servizio.

In quest’ultimo periodo mi rendo sempre più conto che quando sento parlare di architettura, applicata ad uno scenario reale, sento sempre parlare di una sola architettura, perché tendiamo a pensare all’applicazione, o peggio ancora al sistema, nel suo insieme.

I bounded context di DDD, che possono essere per certi versi accumunati con i servizi di SOA, sono e devono essere isolati, esattamente come i servizi, altrimenti non si chiamerebbero bounded :-)

Dato che sono isolati e potenzialmente lo possono essere anche dal punto di vista del deploy perché ci danniamo per far si che la stessa scelta architetturale sia adottata da tutti i servizi? Potremmo giovare di motori di persistenza diversa, di design architetturali diversi, il tutto in base al contesto, i requisiti e le necessità del momento.

Invece no: se abbiamo scelto `event sourcing` (la prima che mi è venuta in mente) allora ci ostiniamo a fare tutto con `event sourcing` ritrovandoci di conseguenza a fare magheggi tecnologici ove `event sourcing` non sia la scelta adeguata.

Comincio a sospettare che, noi dev, siamo causa di più grattacapi di quelli che risolviamo :-)