DDD: ¿Debería encajar todo en Entidad u Objeto de valor?

Question

Intento seguir DDD, o al menos mi limitado entendimiento de esto.

Aunque tengo problemas para instalar algunas cosas en las cajas de DDD.

Un ejemplo: tengo una entidad de usuario. Esta entidad de usuario tiene una referencia a un objeto UserPreferencesInfo; esta es solo una clase que contiene un conjunto de propiedades relacionadas con las preferencias del usuario. Estas propiedades no tienen ninguna relación, aparte del hecho de que todas son preferencias del usuario (a diferencia, por ejemplo, una dirección VO, donde todas las propiedades forman un todo significativo).

Pregunta es - ¿qué es este objeto UserPreferencesInfo?

1) Obviamente no es una entidad (Sólo estoy almacenarla como 'componente' en hablar con fluidez NHibernate (es decir, en la misma mesa DB como la entidad de usuario).

2) VO? Entiendo que Value Object se supone que es Inmutable (por lo que no puede cambiarlos, solo los vuelve a subir). Esto tiene sentido completo cuando el objeto es una dirección, por ejemplo (las propiedades de la dirección forman un 'todo' significativo). Pero en el caso de UserPreferencesInfo, no creo que tenga sentido. Podría haber 100 propiedades (Realísticamente) Podría haber tal vez 20 propiedades en este objeto. ¿Por qué desearía descartar y volver a crear el objeto cada vez que necesite cambiar una propiedad?

Siento que necesito romper las reglas aquí para obtener lo que necesito, pero realmente no me gusta la idea de eso (¡es una pendiente resbaladiza!). ¿Me estoy perdiendo de algo?

Gracias

Answer 1

Por lo que yo entiendo, UserPreferenceInfo es una parte de User entidad. La entidad de usuario de Ergo es una raíz de agregado que se recupera o se guarda usando UserRepository como un todo, junto con UserPreferenceInfo y otros objetos.

Personalmente, creo que UserPreferenceInfo es un tipo de entidad, ya que tiene identidad: se puede cambiar, guardar y recuperar del repositorio y aún se puede considerar como el mismo objeto (es decir, tiene identidad). Pero depende de tu uso de eso.

No importa en qué forma se representa el objeto en el DAL - se almacena en una tabla separada o parte de otra tabla. Uno de los beneficios de DDD es la ignorancia de la persistencia y usualmente es algo bueno.

Por supuesto, puedo estar equivocado, soy nuevo en DDD también.

Answer 2

100 propiedades parece mucho.

Intente dividir UserPreferenceInfo en tipos más pequeños (más cohesivos), que probablemente/ojalá sean manejables como VO.

Answer 3

Yo diría que UserPreferenceInfo es en realidad una parte de la raíz del agregado del usuario. Debería ser responsabilidad del UserRepository conservar la raíz agregada del usuario.

Solo es necesario actualizar los objetos de valor (en su modelo de objetos) cuando se comparten sus valores. Un escenario de ejemplo sería si busca un UserPreferenceInfo similar y asocia al usuario con eso en lugar de insertar uno nuevo cada vez. Compartir objetos de valor tiene sentido si las tablas de objetos de valor se vuelven grandes y aumentan la velocidad/el almacenamiento. El precio para compartir se paga en Insertar. Es razonable abstraer este procedimiento en el DAL.

Si no está duplicando objetos de valor, no hay nada en contra de la actualización.

Answer 4

Aquí está mi granito de arena. Respuesta corta: UserPreferenceInfo es un objeto de valor porque describe las características de un objeto. No es una entidad porque no hay necesidad de rastrear una instancia de objeto a lo largo del tiempo.

Respuesta más larga: un objeto con más de 100 propiedades que no están relacionadas no es muy DDD-ish. Intente agrupar propiedades relacionadas para formar nuevos VO o descubrir nuevas entidades también.

Otro olor a DDD es tener muchas propiedades de conjunto en primer lugar. Intenta encontrar la esencia de la acción en lugar de solo establecer el valor. Ejemplo:

// not ddd 
employee.Salary = newSalary; 

// more ddd 
employee.GiveRaise(newSalary); 

Por otra parte puede muy bien tener razones legítimas para tener un montón de propiedades que no son más que los captadores y definidores. Pero probablemente existan métodos más simples que DDD para resolver el problema. No hay nada de malo en tomar los mejores patrones e ideas de DDD, pero relajar un poco todas las "reglas", especialmente para dominios más simples.

Answer 5

Pregunta es - ¿Qué es este objeto UserPreferencesInfo?

no sé cómo este caso se apoya en NHibernate, pero algunos ORM apoyar a los conceptos especiales para ellos. Por ejemplo, DataObjects.Net incluye el concepto Structures. Parece que necesitas algo como esto en NH.

Answer 6

Respuesta 1 (el práctico)

yo soy un gran defensor de la DDD, pero no lo fuerce. Ya ha reconocido que los VO inmutables agregan más trabajo del requerido. DDD está diseñado para aprovechar la complejidad, pero en este caso hay muy poca complejidad para administrar.

yo simplemente tratar UserPreferencesInfo como Entidad, y hacer referencia a ella desde el agregado User. Ya sea que lo almacene como un Componente o en una mesa separada es su elección.

En mi humilde opinión, todo el debate de Entity vs VO puede hacerse discutible. Es muy poco probable que dentro de 6 meses, otro desarrollador revise su código y diga "WTF! No está usando VO inmutables! ¡¿Qué diablos estaba pensando?".

Respuesta 2 (los puristas DDD)

Es UserPreferencesInfo en realidad parte del dominio de negocio? Otros han mencionado diseccionar este objeto. Pero si se adhiere a DDD puro, es posible que necesite determinar qué preferencias pertenecen a qué contexto Bounded.

Esto a su vez podría dar lugar a la adición de Capas de servicio de, y antes de que te des cuenta, has más de la ingeniería de la solución para un problema muy simple ...

Answer 7

La primera vez que publicar en un blog. Espero que lo haga bien.

De todos modos, dado que no nos ha mostrado el objeto UserPreferencesInfo, no estoy seguro de cómo se ha construido de modo que pueda tener un número variable de elementos en él.

Si fuera yo, haría una única clase llamada UserPreference, con id, ID de usuario, clave, valor, tipo de pantalla y cualquier otro campo que pueda necesitar. Esta es una entidad. tiene una identificación y está vinculada a un determinado usuario.

Luego en su entidad de usuario (la raíz lo asumo), tenga un ISet.