Validación en DDD

214 views
Skip to first unread message

Jorge Escobar

unread,
Oct 11, 2019, 7:23:39 PM10/11/19
to DDD-es
Estamos en el proceso de migrar a una perspectiva DDD en lugar de nuestra perspectiva centrada en la base de datos.

Estamos considerando usar Clean Architecture pero algunas funcionalidades como la validación parecerían pertenecer a las entidades del Dominio, pero como el dominio no debería conocer el repositorio.

Así que estamos considerando si debería estar en la capa de aplicación.


Cualquier sugerencia sería muy bienvenida.

Salud O2


Jorge 

Diego Fontdevila

unread,
Oct 13, 2019, 5:11:06 PM10/13/19
to ddd...@googlegroups.com
Jorge no me queda clara la objeción a poner las validaciones en el dominio, para mí esa es la opción por defecto ¿Por qué es que no lo harías? ¿De qué tipos de validaciones estamos hablando?

Saludos,

Diego

--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ddd-es+un...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/ddd-es/7f4fb27f-7343-411f-bab3-7359b87c0a33%40googlegroups.com.

Jorge Escobar

unread,
Oct 13, 2019, 5:50:43 PM10/13/19
to ddd...@googlegroups.com
Bueno, por ejemplo no repetir un mismo producto, la idea sería que el dominio no tenga acceso a la fuente de datos



El 13 oct. 2019 5:11 p. m., "Diego Fontdevila" <dfo...@gmail.com> escribió:
Jorge no me queda clara la objeción a poner las validaciones en el dominio, para mí esa es la opción por defecto ¿Por qué es que no lo harías? ¿De qué tipos de validaciones estamos hablando?

Saludos,

Diego

On Fri, Oct 11, 2019, 8:23 PM Jorge Escobar <jorgees...@gmail.com> wrote:
Estamos en el proceso de migrar a una perspectiva DDD en lugar de nuestra perspectiva centrada en la base de datos.

Estamos considerando usar Clean Architecture pero algunas funcionalidades como la validación parecerían pertenecer a las entidades del Dominio, pero como el dominio no debería conocer el repositorio.

Así que estamos considerando si debería estar en la capa de aplicación.


Cualquier sugerencia sería muy bienvenida.

Salud O2


Jorge 

--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ddd-es+unsubscribe@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/ddd-es/7f4fb27f-7343-411f-bab3-7359b87c0a33%40googlegroups.com.

--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ddd-es+unsubscribe@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/ddd-es/CADQxVZBkK4JwEXm5bmmPmvzubzGeGFhU2GmqUK8L4Y%2B4KKmG2g%40mail.gmail.com.

Diego Fontdevila

unread,
Oct 15, 2019, 7:01:38 PM10/15/19
to ddd...@googlegroups.com
Gracias por la respuesta,creo que las validaciones como no repetir un mismo producto, podrían estar en los repositorios, el cambio sería que no estarían en las fuentes de datos.

Saludos,
Diego

El dom., 13 de oct. de 2019 a la(s) 18:50, Jorge Escobar (jorgees...@gmail.com) escribió:
Bueno, por ejemplo no repetir un mismo producto, la idea sería que el dominio no tenga acceso a la fuente de datos


El 13 oct. 2019 5:11 p. m., "Diego Fontdevila" <dfo...@gmail.com> escribió:
Jorge no me queda clara la objeción a poner las validaciones en el dominio, para mí esa es la opción por defecto ¿Por qué es que no lo harías? ¿De qué tipos de validaciones estamos hablando?

Saludos,

Diego

On Fri, Oct 11, 2019, 8:23 PM Jorge Escobar <jorgees...@gmail.com> wrote:
Estamos en el proceso de migrar a una perspectiva DDD en lugar de nuestra perspectiva centrada en la base de datos.

Estamos considerando usar Clean Architecture pero algunas funcionalidades como la validación parecerían pertenecer a las entidades del Dominio, pero como el dominio no debería conocer el repositorio.

Así que estamos considerando si debería estar en la capa de aplicación.


Cualquier sugerencia sería muy bienvenida.

Salud O2


Jorge 

--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ddd-es+un...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/ddd-es/7f4fb27f-7343-411f-bab3-7359b87c0a33%40googlegroups.com.

--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ddd-es+un...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/ddd-es/CADQxVZBkK4JwEXm5bmmPmvzubzGeGFhU2GmqUK8L4Y%2B4KKmG2g%40mail.gmail.com.

--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ddd-es+un...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/ddd-es/CAK8r81feH5MwOFiw%3DumL0W%3DKxf9%3D8g4dzgbq3ch%2Be1Cf_d6E%3DA%40mail.gmail.com.


--
Diego
@dfontde

Jorge Escobar

unread,
Oct 24, 2019, 9:32:58 AM10/24/19
to DDD-es
Diego, 

Primero gracias a ti por responder!, 
Segundo mil disculpas por la demora en este follow-up
y finalmente, bueno lo que nos pasa por la cabeza es si las reglas de negocio deberían estar repartidas a través de la arquitectura o deberían centralizarse, por ejemplo son algunos casos más complejos:

Un supervisor y un empleado, el supervisor puede acceder a revisar las acciones de sus empleados, entonces debemos validar por ejemplo que el usuario que se ha logueado sea supervisor del empleado a obtener sus acciones. (esto nos parece que va al Application), sin embargo quizás deberíamos validar primero que el empleado sobre el que se quiere realizar acciones también exista y sea válido, esta última nos parecía que era una regla de dominio... sin embargo deberíamos hacerla antes de revisar inclusive la "pertenencia" que tiene un supervisor a un empleado.

Eso nos hace dudar.

Saludos

Jorge

El martes, 15 de octubre de 2019, 19:01:38 (UTC-4), dfontde escribió:
Gracias por la respuesta,creo que las validaciones como no repetir un mismo producto, podrían estar en los repositorios, el cambio sería que no estarían en las fuentes de datos.

Saludos,
Diego

El dom., 13 de oct. de 2019 a la(s) 18:50, Jorge Escobar (jorgees...@gmail.com) escribió:
Bueno, por ejemplo no repetir un mismo producto, la idea sería que el dominio no tenga acceso a la fuente de datos


El 13 oct. 2019 5:11 p. m., "Diego Fontdevila" <dfo...@gmail.com> escribió:
Jorge no me queda clara la objeción a poner las validaciones en el dominio, para mí esa es la opción por defecto ¿Por qué es que no lo harías? ¿De qué tipos de validaciones estamos hablando?

Saludos,

Diego

On Fri, Oct 11, 2019, 8:23 PM Jorge Escobar <jorgees...@gmail.com> wrote:
Estamos en el proceso de migrar a una perspectiva DDD en lugar de nuestra perspectiva centrada en la base de datos.

Estamos considerando usar Clean Architecture pero algunas funcionalidades como la validación parecerían pertenecer a las entidades del Dominio, pero como el dominio no debería conocer el repositorio.

Así que estamos considerando si debería estar en la capa de aplicación.


Cualquier sugerencia sería muy bienvenida.

Salud O2


Jorge 

--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ddd...@googlegroups.com.

--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ddd...@googlegroups.com.

--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a ddd...@googlegroups.com.


--
Diego
@dfontde

Carlos Peix

unread,
Oct 24, 2019, 10:08:13 AM10/24/19
to ddd-es
Hola Jorge, respondo interlineado

----------------------
Carlos Peix

On Thu, Oct 24, 2019 at 10:33 AM Jorge Escobar <jorgees...@gmail.com> wrote:
Un supervisor y un empleado, el supervisor puede acceder a revisar las acciones de sus empleados, entonces debemos validar por ejemplo que el usuario que se ha logueado sea supervisor del empleado a obtener sus acciones. (esto nos parece que va al Application),

Para eso creo que puede bastar el modelo de dominio (no hace falta recurrir a otros espacios). Por ejemplo, me imagino que la persona que es supervisor tendrá adosado ese rot (hay patrones de diseño para resolver eso). Y, en ese caso, me imagino que ese rol tendrá asociadas personas como empleados (una colección de personas del rol Supervisor)

Entonces no hace falta validar, si no tiene el rol, no es supervisor, por tanto, no tiene empleados asociados.
 
sin embargo quizás deberíamos validar primero que el empleado sobre el que se quiere realizar acciones también exista y sea válido, esta última nos parecía que era una regla de dominio... sin embargo deberíamos hacerla antes de revisar inclusive la "pertenencia" que tiene un supervisor a un empleado.

Esto también me parece simple. No buscamos entre todos los empleados de la organización. Buscamos solo en la colección de supervisados de ese rol Supervisor, de donde surge que es imposible que acceda a otros empleados.

Te suena razonabe?
Reply all
Reply to author
Forward
0 new messages