Estoy aprendiendo DDD (el libro de Eric Evans está abierto frente a mí) y me he encontrado con un problema para el que no puedo encontrar una respuesta. ¿Qué haces en DDD cuando solo estás tratando de obtener una lista simple de registros de búsqueda?

Ex

EmployeeID: 123
EmployeeName: John Doe
Estado: Alaska (desplegable)
County: Wasilla (desplegable - se filtrará según el estado).

Por ejemplo, supongamos que tiene un objeto de dominio Employee, una interfaz IEmployeeRepository y una clase EmployeeRepository. Esto lo utilizará una IU para mostrar una lista de empleados y detalles individuales. En la interfaz de usuario, desea utilizar un menú desplegable para el estado y el condado donde vive el empleado. Los condados disponibles se filtrarán según el estado elegido.

Desafortunadamente, las tablas de la base de datos y la interfaz de usuario se ven muy diferentes. En tblEmployees, contiene el Código de estado = AK y el Código de condado = 02130, no los Nombres de estado y condado.

La forma anterior (antes de comenzar esta búsqueda DDD) sería bastante simple, solo crea 2 consultas y usa un DataReader para completar los menús desplegables. Debajo de la pantalla en los menús desplegables está el valor, que se usa automáticamente en las publicaciones de formulario.

Con DDD, sin embargo, no estoy seguro de cómo se supone que debes hacer esto. Primero comencé creando objetos estatales y del condado, así como repositorios e interfaces para los repositorios. Sin embargo, escribir 4 clases + 2 interfaces y la plomería en los archivos hbm.xml + objetos de Empleado de negocios parece excesivo para solo 2 consultas para 2 menús desplegables. Tiene que haber una mejor manera, ¿no? No voy a cambiar los registros en las tablas del Estado o del Condado en el corto plazo e incluso si lo hiciera, no sería a través de esta aplicación. Por lo tanto, no quiero crear objetos comerciales para el Estado y el Condado si no tengo que hacerlo.

La solución más simple que veo es crear una clase auxiliar con métodos que devuelvan diccionarios, como GetStatesAll (), GetState () y GetCounties () y GetCounty (), pero eso se siente mal desde una perspectiva DDD.

Por favor ayuda. ¿Cómo puedo usar DDD sin sobreingeniería con solo un par de búsquedas simples?

Solución fina Creo que finalmente encontré mi respuesta a través de la experiencia, que consistía en poner el método GetStates () en su propia clase de acceso a datos, aunque no en una clase de repositorio. Como solo estaba haciendo acceso de solo lectura, lo lancé a una estructura DTO. Como la base de datos era pequeña, los incluí en una sola clase, como lo describe Todd a continuación.

Mis conclusiones:

as tablas @Buscar NUNCA son objetos de valor, porque las tablas de búsqueda SIEMPRE tienen una identidad. Si no tuvieran una identidad, tendrías duplicados, lo que no tendría mucho sentido. La tabla de búsqueda de solo lectura puede tener un repositorio, pero probablemente no lo necesite. El objetivo de un repositorio es reducir la complejidad al forzar el acceso solo a través del agregado. Revisar el agregado le brinda una manera de garantizar que se puedan hacer cumplir las normas comerciales, como no agregar neumáticos si no tiene un automóvil. Si permite el mantenimiento CRUD en la tabla de búsqueda, entonces tiene sentido que la tabla de búsqueda tenga su propio repositorio. El hecho de que terminé almacenando los códigos como estructuras no los convierte en "tipos de valor". Fowler dice en POEAA que una estructura es un tipo de valor. Eso es cierto, las estructuras son inmutables, por eso Fowler dice que son "tipos de valor", sin embargo, los estaba usando de manera diferente. Estaba usando estructuras como una forma liviana de pasar DTO que nunca planeé cambiar después de su creación inicial. En verdad, las estructuras que utilicé tenían identidades, pero como eran de solo lectura funcionaban como estructuras.Un patrón que he estado usando y que no veo mucho en otros lugares es hacer que los campos clave principales sean inmutables. Los establece el constructor, pero son de solo lectura (no de accesos privados) y no se pueden cambiar una vez que se crea el objeto.