Cómo tratar con un objeto de valor que necesita buscar datos en la base de datos

Question

Estoy comenzando con el estudio del diseño impulsado por dominio y es bastante posible que mi comprensión de la división Entidades/Valores sea defectuosa, por lo tanto, si es así que por favor házmelo saber.

Según mi entender, dado que su identidad está completamente definida por sus propiedades, una dirección es el objeto de valor por excelencia. Según entiendo, esto significa, entre otras cosas, que no debe haber un repositorio separado o un objeto de acceso a datos para las direcciones.

Esto me crea un dilema ya que en mi caso una dirección contiene un país donde un país tiene un nombre y un código de país y se supone que la lista de códigos de país se carga desde la base de datos.

Mi pregunta es, ¿cómo puedo diseñar esto? Quiero que las personas puedan crear una dirección utilizando el nuevo operador, pero no quiero crear un objeto de acceso a datos para el país y, si lo hago, ciertamente no quiero poner una referencia en el objeto de dirección.

Tengo algunas ideas, pero me gustaría escuchar cualquier sugerencia que alguien pueda tener.

Answer 1

Esto crea un dilema para mí ya que en mi caso de una dirección contiene un País Cuando un país tiene un nombre y un código de país y la lista de países códigos se supone que se va a cargar en de la base de datos.

El objeto Address no tiene una lista de países como su propiedad. Por el contrario, tendría una sola instancia del objeto del país. La capa de presentación proporcionará una lista de objetos de país, que probablemente residan en una lista desplegable. Al cargar una dirección específica, debe establecer el valor de la lista desplegable igual al ID del país del objeto que es una propiedad del objeto Dirección. En otras palabras:

(que contiene una lista de objetos País) Valor objeto seleccionado = address.Country o myDropDown del valor de la clave de myDropDown = address.Country.ID

Ahora, para poblar la capa de presentación, el acceso a datos Layer debería proporcionar una función que devuelva una lista sin formato de objetos Country. De una manera .NET, sería algo así como:

Namespace Dal 

    Public NotInheritable Class Countries 
    ... 
    Public Shared Function Read(ByVal countryId as Integer) As BusinessObjects.Country 
    ... 
    Public Shared Function ReadList() As List(Of BusinessObjects.Country) 
    ... 

Answer 2

Permítanme comenzar diciendo que mi única experiencia con el diseño impulsado dominio estaba leyendo el artículo de Wikipedia hace unos minutos. Dicho esto, aquí están mis pensamientos sobre su pregunta:

Estoy de acuerdo en que el objeto de dirección no requiere ningún objeto de acceso a datos, ¿qué tal una fábrica de direcciones que maneja los códigos de país y construye objetos de dirección basados ​​en las entradas de ¿el usuario? De esta manera, la fábrica mantendría los objetos de acceso a datos, y su objeto de dirección podría permanecer solo de valor.

Si esto no es kosher según DDD, házmelo saber. Tengo curiosidad por ver qué se le ocurre al resto de la comunidad.

Answer 3

no hay nada en DDD que impida que los objetos de valor retengan referencias a las entidades. Por lo tanto, su dirección tendría una referencia a una entidad del país.

Answer 4

Yendo de la manera DDD, primero pensaría en las necesidades de su aplicación y construiría el modelo desde allí.

No debe preocuparse porque el país se use solo en la dirección. No está mal convertirlo en una Entidad per se. La pregunta principal es: ¿piensas en un país como algo que tiene una identidad, o está definido solo por atributos? Si tiene dos países con el mismo nombre (y el mismo código de país), ¿puede ver alguna diferencia?

Quizás debería considerar hacer de Country un objeto de valor. No le impide tener alguna lista de carga de repositorio de países de DB, o cargando País en función de su código. En el lado de la implementación, su repositorio aún puede cargar la lista de países de la base de datos una vez y guardarla en la memoria caché. O podría tenerlo codificado, o leer desde XML. A su modelo de dominio no le importaría.

Probablemente creará un método de fábrica en Dirección que acepte código de país entre otros parámetros. Luego usaría el repositorio para crear una instancia de país y devolver un objeto de dirección correcto.

Pensar en los agregados también puede generar algunas ideas sobre el diseño del repositorio.

Espero que esto ayude