Sto lavorando alla mia prima applicazione DDD "reale".DDD. Dove appartengono le impostazioni configurabili dall'utente?
Attualmente il mio client non ha accesso al mio livello dominio e richiede modifiche al dominio tramite l'emissione di comandi.
Ho quindi un modello di lettura separato (appiattito) per la visualizzazione delle informazioni (come il semplice CQRS).
Ora sto lavorando alla configurazione, o in particolare alle impostazioni che l'utente configura. Utilizzando l'applicazione blog come esempio, le impostazioni potrebbero essere il titolo o il logo del blog.
Ho sviluppato un generatore di configurazione generico che crea un oggetto di configurazione fortemente tipizzato (ad esempio BlogSettings) basato su una semplice coppia di valori chiave. Sono bloccato se questi oggetti di configurazione fanno parte del mio dominio. Ho bisogno di accedere a loro dal client e dal server.
Sto pensando di creare una libreria "condivisa" che contenga questi oggetti di configurazione. È questo l'approccio corretto?
Infine dove dovrebbe essere il codice per salvare tali impostazioni di configurazione dal vivo? Una soluzione semplice sarebbe quella di inserire questo codice nel mio progetto Domain.Persistence, ma poi, se non fanno parte del dominio, dovrebbero essere davvero lì?
Grazie,
Ben impostazioni configurabili
Un altro modo di guardarlo potrebbe essere che si dispone di un contesto limitato "Configurazione" o "Impostazioni" separato. È una separazione logica, non fisica. In questo modo è possibile continuare a fornire l'accesso al contesto utilizzando varie tecnologie (client vs server). Tutto il codice per farlo, tuttavia, appartiene al contesto. –
@YvesReynhout questo è il percorso che abbiamo finito, con un contesto di configurazione con cui interagiamo. Tuttavia, abbiamo reso gli oggetti di configurazione condivisi: in questo caso, la separazione avrebbe semplicemente causato una duplicazione non necessaria del codice. –
Oh, ma la separazione logica non porta alla duplicazione del codice. Significa solo che il contesto limitato è responsabile del codice. Il modo in cui viene implementato il codice del contesto limitato è completamente ortogonale a tale fatto (potrebbe essere perfettamente ospitato all'interno di un processo insieme al codice di altri contesti limitati). –