2012-10-13 49 views
10

Como parte de mi modelo de dominio, digamos que tengo un objeto WorkItem. El objeto WorkItem tiene varias relaciones para buscar valores como:¿Deben modelarse los valores de búsqueda como raíces agregadas?

WorkItemType:

  • historias de usuario
  • Bug
  • Enhancement

Priority:

  • alta
  • Medio
  • baja

Y, posiblemente, podría haber más, como Status, Severity, etc ... afirma

DDD que si existe algo dentro de una raíz agregado que usted no debe Intente acceder a él fuera de la raíz agregada. Entonces, si deseo poder agregar nuevos WorkItemTypes como Task o nuevas Prioridades como Critical, ¿esos valores de búsqueda deben ser raíces agregadas con sus propios repositorios? Esto parece un poco exagerado, especialmente si solo son un par de valores clave. ¿Cómo debo permitir que un usuario modifique estos valores y cumpla con la regla de encapsulación de raíz agregada?

Respuesta

6

Landon, creo que la única forma es hacer que esos pares de valores agreguen raíces. Sé que puede parecer excesivo, pero eso es DDD que frena las cosas en pequeños componentes.

Las razones por las que creo el uso de un repositorio es la manera correcta son:

  • Un usuario debe ser capaz de añadir los pares de valores de forma independiente de un elemento de trabajo.
  • Los pares de valores no tienen una identidad local, único

Recuerde que DDD es sólo un conjunto de directrices, no verdades duras. Si crees que esto es excesivo, es posible que desees crear una búsqueda que devuelva los pares como objetos de valor. Esto podría funcionar especialmente si no tiene una función para agregar pares de valores en la aplicación, sino a través de la base de datos.

Como nota al margen, ¡buena pregunta! Hay bastantes publicaciones en el blog sobre estas situaciones ... Pero no todas coinciden en la mejor forma de hacerlo.

+0

En mi caso, la aplicación necesita modificar los valores de búsqueda. Supongo que modelar estos objetos como agregados parece tener sentido. Vaughn Vernon tiene una explicación de cómo estos agregados pueden funcionar juntos en este [artículo] (http://dddcommunity.org/sites/default/files/pdf_articles/Vernon_2011_2.pdf). En la parte inferior de la página 8, menciona que podría hacer que un servicio de aplicaciones resuelva las dependencias. También afirma que si las consultas se vuelven demasiado costosas, podría usar CQRS. –

4

No todo debe modelarse con DDD. La complejidad de la administración de los datos de referencia probablemente no justifique la creación de raíces agregadas. Una solución común sería usar CRUD para administrar los datos de referencia y tener un Servicio de dominio para interactuar con esos datos del dominio.

8

Si bien el patrón de repositorio descrito en blue book hace hincapié en que su uso es exclusivo de los agregados, deja espacio para excepciones.Para citar el libro:

Aunque la mayoría de las consultas devuelven un objeto o una colección de objetos, que también encaja dentro del concepto de volver algunos tipos de resumen cálculos, como un recuento de objetos, o una suma de una numérico atributo que fue diseñado por el modelo para ser contado. (Pág. 152)

Esto indica que un repositorio puede utilizarse para devolver información de resumen, que no es un agregado. Esta idea se extiende al uso de un repositorio para buscar objetos de valor, tal como lo requiere su caso de uso.

Otra cosa a tener en cuenta es el read-model pattern que esencialmente permite un tipo de depósito de solo consulta que desacopla efectivamente el modelo de dominio rico en comportamiento de los problemas de consulta.

+0

+1 para señalar que un repositorio no siempre tiene que devolver una raíz agregada. También para ver el vínculo con el patrón del modelo de lectura y explicar cómo difiere de CQRS porque comparte la misma base de datos. Como mi aplicación requiere cambios de datos y no solo lecturas, he decidido hacer que agreguen raíces y, probablemente, utilicen un modelo de lectura o un servicio de aplicaciones para establecer las asociaciones entre los agregados. –

2

¿Estas búsquedas tienen ID's? De lo contrario, podría considerar hacerlos Value Objects ...

+2

Tienen identificaciones y son compartidas por instancias de entidades diferentes, por lo que no son objetos de valor. –

Cuestiones relacionadas