Estoy trabajando en mi primera aplicación DDD "real".DDD. ¿A dónde pertenecen las configuraciones configurables por el usuario?
Actualmente mi cliente no tiene acceso a mi capa de dominio y solicita cambios en el dominio mediante la emisión de comandos.
Luego tengo un modelo de lectura separado (aplanado) para mostrar información (como CQRS simple).
Ahora estoy trabajando en la configuración, o específicamente, las configuraciones que configura el usuario. Usando una aplicación de blog como ejemplo, la configuración puede ser el título o logotipo del blog.
He desarrollado un generador de configuración genérico que construye un objeto de configuración fuertemente tipado (por ejemplo, BlogSettings) basado en una colección simple de pares de valores clave. Estoy atascado sobre si estos objetos de configuración son parte de mi dominio. Necesito acceso a ellos desde el cliente y el servidor.
Estoy considerando crear una biblioteca "Compartida" que contenga estos objetos de configuración. ¿Es este el enfoque correcto?
Finalmente, ¿dónde debería estar el código para guardar tales configuraciones de configuración en vivo? Una solución fácil sería poner este código en mi proyecto de Persistencia de Dominio, pero luego, si no son parte del dominio, ¿deberían estar realmente allí?
Gracias,
Ben opciones configurables
Otra forma de verlo podría ser que tiene un contexto delimitado por separado "Configuración" o "Configuraciones". Es una separación lógica, no física. Por lo tanto, puede seguir brindando acceso al contexto utilizando diversas tecnologías (cliente vs servidor). Sin embargo, todo el código para hacerlo pertenece al contexto. –
@YvesReynhout esta es la ruta que terminamos yendo, teniendo un contexto de configuración con el que interactuamos. Sin embargo, sí hicimos que los objetos de configuración se compartieran; en este caso, la separación simplemente habría causado la duplicación innecesaria del código. –
Ah, pero la separación lógica no conduce a la duplicación de código. Simplemente significa que el contexto delimitado es responsable del código. Cómo se despliega el código del contexto delimitado es completamente ortogonal a este hecho (podría alojarse perfectamente dentro de un proceso junto con el código de otros contextos delimitados). –