Diseño controlado por el dominio: ¿dónde pertenece el análisis de datos?

Question

En esta aplicación que estoy desarrollando, el dominio gira en torno a, digamos, aparatos eléctricos. Hay varias versiones especializadas de esta entidad. Los dispositivos se pueden enviar a la aplicación, y esto sucede desde los servicios web que utilizan objetos de transferencia de datos.

Si bien esto está funcionando bien, ahora también estoy buscando importar aplicaciones de varios formatos de archivo basados ​​en texto. Considere este flujo de trabajo:

1. servicio de directorio observador ve un archivo nuevo aparato ha sido añadido
2. El servicio utiliza un servicio de aplicación de mi solicitud para someter los aparatos descritos por el archivo

Ahora, el el servicio de aplicación podría tener un método con el siguiente nombre y firma: ApplianceService.Register(string fileContents). Estoy pensando que el servicio de observador de directorio usará este método de servicio y le pasará todo el contenido del archivo. El servicio de aplicación coordinará el análisis. Analizar los contenidos del archivo y transformarlo en entidades completas de dispositivos implica varios pasos. Ahora, mi pregunta es:

Pregunta: ¿Es esto correcto, o debería la lógica de análisis vivir dentro del servicio del observador del directorio? Cada tipo de formato de archivo es tipo de una parte del dominio, pero, una vez más, no lo es. Después de que los archivos se hayan analizado en entidades de cualquier formato, la entidad nunca sabrá que una vez se representó usando ese formato. Si la lógica de análisis debe vivir dentro del servicio del observador, pasaría los nuevos dispositivos al servicio de registro como objetos de transferencia de datos.

Supongo que lo que me preocupa es cómo debe representarse un dispositivo antes de que entre en mi aplicación (utilizando la capa de aplicación como punto de entrada). Al enviar dispositivos desde servicios web, paso una secuencia de objetos de transferencia de datos del dispositivo. Esto es diferente de tomar un archivo con un formato potencialmente extraño y analizarlo en un objeto de transferencia de datos, ya que la asignación de la solicitud del servicio web al objeto de transferencia de datos es bastante sencilla, y no tan compleja.

Cualquier idea al respecto es muy bienvenida.

Answer 1

Según SRP (principio de responsabilidad única), debe tener en cuenta. Directory Watcher service debe hacer lo que mejor hace: ver los archivos nuevos en un directorio y pasarlos a otro servicio, es decir, Appliance Service, que los convierte en objetos de transferencia de datos. Ahora puede usar su web services para enviar esos objetos de transferencia de datos a la Aplicación.

Haría una interfaz para Appliance Service, con al menos un método llamado Convert(). Appliance Parsing Service clase puede implementar la interfaz. Digamos luego que tienes una fuente diferente (SQL) para los dispositivos. Puede escribir otra clase Appliance SQL Service que implemente Appliance Service.

Answer 2

Yo diría que el ApplicationService es el lugar correcto para la lógica de análisis sintáctico, pensó que no sería del todo incorrecto ponerlo en el servicio de DirectoryWatcher.

Mi razonamiento para esa afirmación proviene del principio del Principio de Responsabilidad Individual: el DirectoryWatcher en particular no debería ser responsable de administrar todos los diversos formatos de archivos de entrada. Simplemente debería tomar lo que recibe y pasarlo al lugar correcto (ya una responsabilidad muy involucrada).

Cuando mi cabeza se revolvió un poco (¿y quizás lo mismo que usted?) Fue que no es realmente responsabilidad del ApplicationService el que coordina las diversas entidades de dominio. Sin embargo, creo que el ApplicationService es el lugar adecuado para aprovechar algún tipo de patrón de Builder, abstrayendo los detalles de cada método de análisis de cada archivo pero también creando un lugar claro en el dominio donde se coordina este análisis.

En cuanto a cada formato de archivo que forma parte del dominio o no. Yo diría que sí. Puedes imaginarlos a todos expresados ​​como parte del lenguaje omnipresente, con varios expertos de dominio hablando sobre las peculiaridades del formato de archivo x o formato de archivo y los datos expresados. Ese tipo de análisis y mapeo es una lógica de dominio de primera clase.

Otro buen lado de su diseño original es que creo que simplificaría la adición de nuevas fuentes de archivos de entrada y formatos y la modificación de los ya existentes. Ha desacoplado el origen del archivo del formato específico y ha creado un punto de interfaz agradable (ApplicationService) donde sus nuevos proveedores de archivos acceden a las aplicaciones principales.