Al cruzar conceptos dentro de un Modelo de dominio donde existe algo que tiene un nombre y suena como un objeto, pero se superpone con la responsabilidad de uno de los 5 principales DDD bloquea ¿cuál es la mejor práctica para nombrar este objeto y/o tratar con el diseño que puede o no incluir ese nombre o frase en la implementación real?Denominación de objetos de dominio que actúan como bloques de construcción ddd como repositorios
Para dar un ejemplo más concreto digamos que estamos diseñando una aplicación de seguimiento de tiempo en el espíritu de DDD y encontramos algo que los expertos de dominio llaman un "registro de tiempo" que se supone que es el registro que contiene el golpe -in y los tiempos de lanzamiento correspondientes para todos los empleados.
Con esta información mi pensamiento inicial es que si hubiera una clase escrita llamada TimeLog que permitiera consultar entradas de tiempo existentes y también para entradas de registro de tiempo nuevas o corregidas persistentes, esa clase realmente está desempeñando el papel de un repositorio DDD . Por simplicidad, supongamos que después de varias discusiones y refactorizaciones llegamos a la conclusión de que cada vez que la entrada de registro es esencialmente su propia raíz agregada, tiene la necesidad de un repositorio correspondiente.
Ahora nos queda la opción de nombrar a nuestro repositorio como TimeLog que parece más acorde con el concepto DDD del lenguaje ubicuo o podríamos llamarlo TimeLogEntryRepository que parece ajustarse a la convención más general para nombrar Repositorios después de la raíz Agregado que consultan/persisten. Me inclino más hacia la idea de utilizar TimeLog ya que es más descriptivo de la función real que desempeña en el modelo de dominio, lo que a su vez ayuda a comunicar el diseño a los expertos en el dominio. La opción de usar TimeLogEntryRepository por otro lado sigue las convenciones DDD existentes y por lo tanto haría el diseño más fácil de seguir para los desarrolladores. También se puede llegar a un acuerdo con la asignación de nombres TimeLog, pero para que todos los repositorios implementen una interfaz IRepository o hereden de una clase base Repository común para ayudar a los desarrolladores a localizar y distinguir las clases de repositorio de otras que conforman el modelo de dominio. La principal preocupación que tengo con el uso de una clase base es que puede alentar el uso de interfaces de marcadores o una clase base débil e innecesaria solo para fines de organización y no debido a factores de comportamiento.
¿Cuál es la mejor práctica en casos como este? Puedo ver el mismo tipo de problema que puede ocurrir para los servicios, ya que son otra pieza de los típicos bloques de desarrollo de DDD que los desarrolladores suelen nombrar usando un sufijo de "Servicio" como SomeComplexActivityService, pero para Entidades y Objetos de valor esto realmente no es un problema . Estoy especialmente interesado en ver lo que otros pueden decir que tienen más experiencia de DDD en su haber.
estaba pensando la palabra Registrador o del Registro puede tener más sentido, pero después de pasar a googlefight.com Me sorprendió ver registrator se lleva la palma por un amplio margen. http://googlefight.com/index.php?lang=en_GB&word1=registrar&word2=registrator – jpierson
1, leí el artículo que se ha vinculado y resulta que presentan una interfaz fluida ordenada construido para sí mismos repositorios que es bastante limpio . No estoy seguro de si quiero llevar las cosas tan lejos, pero puedo ver dónde están sus beneficios. – jpierson