Sto considerando come impostare i confini precisi dei contesti limitati. Considerando che un contesto limitato è uno spazio di soluzione, a volte è molto difficile impostare esattamente lo spazio della soluzione.
Ecco un esempio. Ho i seguenti contesti limitati
- Ordine
- Messaggi
- Gestione dei contenuti
- Magazzino ecc.
Quindi in una situazione di vita reale questa è una possibile situazione
- L'ordine deve inviare una notifica
- L'ordinazione ottiene una bozza del messaggio dalla gestione dei contenuti
- L'ordine formatta un messaggio e lo inoltra alla messaggistica
- La messaggistica invia una notifica e fa tutto il lavoro rilevante per quel BC (invia un messaggio, lo archivia, lo registra ecc.)
Sembra un progetto valido, ma ho dei dubbi a riguardo. Ad esempio, se Messaging dovesse essere parte di uno "spazio soluzione" per l'ordine e anche forse "spazio soluzione" del Magazzino (non come BC naturalmente, proprio come il codice). In tal caso, la progettazione di Messaging potrebbe cambiare per ogni "spazio soluzione" in base alle proprie esigenze (se presenti).
Tirando fuori da più BC ho voluto che Messaging fosse una parte dello "spazio di soluzione" di Messaging (per risolvere i requisiti del processo di messaggistica), quindi un BC diverso può usarlo (livello anti-corruzione) senza duplicare la sua logica in più BC.
Entrambi gli scenari sono validi, il primo scenario tende a far dipendere altri BC da Messaging BC senza codice duplicato, mentre altri scenari offrono piena autonomia a ciascun BC, nessun messaggio di messaggistica BC, codice "duplicato" e probabilmente più elevato di risorse in quel BC .
Quindi potrebbe essere un buon modo per definire i confini di un problema / spazio soluzione? Dovrebbe essere basato su alcune linee guida DDD, limiti delle risorse hardware o qualcos'altro?