Configuración de nivel de aplicación en DDD?

Question

Solo quería que los grupos pensaran sobre cómo manejar los detalles de configuración de las entidades.

Lo que estoy pensando específicamente es la configuración de alto nivel que podría ser modificada por el administrador. el tipo de cosas que puede almacenar en la aplicación o en la web. Definitivamente, en última instancia, desde la perspectiva de DDD debe establecerse en algún lugar de los objetos explícitamente.

Como argumento, tomemos como ejemplo una aplicación de blog o CMS basada en web.

Una entidad de entrada de blog dada tiene cualquier número de configuración de la instancia como autor, contenido, etc.

Pero también puede ser que desee establecer (por ejemplo) la descripción o palabras clave que todas las entradas en el sitio deben empezar por defecto si el autor no los cambia Claro, podrías hacer esas constantes en la clase, pero luego el propietario del sitio no podría cambiar los valores predeterminados.

Así que mis pensamientos son los siguientes:

1) utilizar clase de nivel() propiedades estáticas que representan esos ajustes, y luego los puso cuando la aplicación se inicia, ya sea la que fueron desde la base de datos o desde la Web .config.

o

2) el uso de una entidad separada para la celebración de la configuración, posiblemente, un diccionario, o bien utilizarlo directamente o tienen que ser un miembro de la clase de entrada

Lo que todas las huelgas como la más fácil/flexible? Mi preocupación sobre la primera es que no me parece muy conectable (si termino queriendo agregar más características) ya que cambiar los métodos de clase de una entidad me haría cambiar la aplicación también (lo cual se siente como una violación de OCP)) Sin embargo, el segundo parece ser más pesado, especialmente si luego tengo que emitir o analizar valores del diccionario.

Answer 1

Yo diría que si un valor es configurable o no es irrelevante desde la perspectiva del Modelo de Dominio, lo que importa es que está definido externamente.

Digamos que usted tiene una clase que debe tener un nombre. Si el nombre siempre es obligatorio, debe estar encapsulado como invariable independientemente de la fuente del valor. Aquí hay un ejemplo de C#:

public class MyClass 
{ 
    private string name; 

    public MyClass(string name) 
    { 
     if(name == null) 
     { 
      throw new ArgumentNullException("name"); 
     } 

     this.name = name; 
    } 

    public string Name 
    { 
     get { return this.name; } 
     set 
     { 
      if(value == null) 
      { 
       throw new ArgumentNullException("name"); 
      } 
      this.name = value; 
     } 
    } 
} 

Una clase como esta protege efectivamente el invariante: el nombre no debe ser nulo. Los Modelos de dominio deben encapsular invariantes como este sin tener en cuenta qué consumidor los usará; de lo contrario, no cumplirían el objetivo de Diseño flexible.

Pero usted ha preguntado acerca de los valores predeterminados. Si tiene un buen valor predeterminado para Nombre, ¿cómo comunica ese valor predeterminado a MyClass?

Aquí es donde las fábricas son útiles. Simplemente separe la construcción de sus objetos de su implementación. A menudo, esta es una buena idea en cualquier caso. Ya sea que elija una fábrica abstracta o la implementación de Builder es menos importante, pero Abstract Factory es una buena opción predeterminada.

En el caso de MiClase, podríamos definir la interfaz IMyClassFactory:

public interface IMyClassFactory 
{ 
    MyClass Create(); 
} 

Ahora puede definir una aplicación que extrae el nombre de un archivo de configuración:

public ConfigurationBasedMyClassFactory : IMyClassFactory 
{ 
    public MyClass Create() 
    { 
     var name = ConfigurationManager.AppSettings["MyName"]; 
     return new MyClass(name); 
    } 
} 

Asegúrese de que el código que necesita instancias de MyClass use IMyClassFactory para crearlo en lugar de actualizarlo manualmente.