[ADD] Hangout debate sobre diseño basado en DDD con @eferro

[Carlos Peix]

Hola amigos,

Producto de un hilo de este grupo y luego una sesión en el AOS2015 en Asturias, les comparto este hangout que tendremos mañana sobre DDD con Eduardo Ferro.

https://plus.google.com/u/0/events/c1rk3fnk0gs5rc7nbn8on9jkpgo

Nos vemos!

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

[Victor Aguayo]

Amigos saludos, tengo algunas dudas con respecto al video, no me queda claro el tema de las entidades cuando manejas bounded context, por ejemplo en un subsistema de venta de pasajes se maneja como entidad Pasajero y en la reserva de hotel Ciente, en ambos subsistemas estas entidades que hablan de un mismo objeto dentro del sistema global podrían tener diferentes propiedades y validaciones, hasta donde entiendo deberían se existir 2 entidades en el dominio? Pasajero con sus propiedades y Cliente con sus propiedades? y usarlas en sus respectivos bounded context?

Gracias por su respuesta

Saludos

[Carlos Peix]

Hola Victor,

Que bueno que encontraste este post tan viejo! Y que bueno que estés en la búsqueda de un mejor modelo de tu dominio...

Creo que puede ayudarte investigar un poco sobre el roles. Conozco poco la terminología y el dominio del turismo pero me suena que Pasajero y Cliente son dos roles distintos con los que vemos a una persona.

La idea del modelado de roles (muy alineado con DDD) es que separás el concepto de Persona, Pasajero, Cliente, etc, entonces, por un lado tenés el modelo Persona, en su bounded context y también tenés el modelo Pasajero en el bounded context de pasajes y el modelo Cliente (o Pax?) en el bounded context de hoteles.

Resta conversar sobre la relación que luego establecés entre Persona y Pasajero. Una de las opciones que me gusta es crear dos tipos separados (Persona y Pasajero). En el modelo Pasajero las responsabilidades (y estado) relacionados con el pasajero. También coloco una referencia al modelo Persona, donde estan las responsabilidades (y estado) de la persona, de manera que, si necesito el nombre del pasajero, ese método delega en el modelo persona.

Mas información en estos links (en inglés):

https://www.martinfowler.com/apsupp/roles.pdf

https://hillside.net/plop/plop97/Proceedings/riehle.pdf

Un saludo!

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

--
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 publicar en este grupo, envía un correo electrónico a ddd...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/ddd-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Victor Aguayo]

Carlos muchísimas gracias por tu respuesta siempre ilustrativa, voy a darle una leida a los links que has dejado, gracias, tengo un par de consultas que me surjen de la pregunta anterior, hablamos de 2 entidades Persona y Pasajero, ambas residirán en la capa de dominio según DDD ya que son entidades, pero ya aterrizando tal vez mas a la estructura y al código la pregunta es por ejemplo en .Net yo tengo las capas planteadas por DDD Presentación, Aplicación, Dominio, Infraestructura y la capa de CrossCuting, bien mi pregunta es cada bounded context tendrá estas 5 capas ?, es que en estas 5 capas estarán contenidas los boundex context?, donde me puedes recomendar mirar en Internet un ejemplo de estructura DDD con mas de un bounded Context para ver la distribución de las capas?

Muchas gracias

Saludos 

Victor Aguayo

[Carlos Peix]

Hola Victor,

En mi opinión, el concepto de bounded contexts solo aplica a la capa de dominio o, mejor dicho, del modelo del dominio.

Un saludo

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

[Victor Aguayo]

Muchas gracias Carlos

Saludos

Victor

[Pepito Fernandez]

Si tienes a Persona y Pasajero en Bounded Contexts diferentes, entonces hay una violacion de tus “boundaries”. Los BC solamente se comunican entre si al subscribirse cada uno a los mensajes que emite el otro. Los únicos objetos que pueden ser compartidos entre Bounded Contexts (y no siempre) son los ValueObjects.

No hay ningun problema con tener algunas propiedades repetidas en tus Entidades. Por ejemplo, los dos tienen nombre y apellidos. Digamos que deseas actualizar el apellido de un Pasajero. La pregunta seria… esta permitido, desde el contexto del Pasajero, actualizar información directamente? O debería actualizar el apellido en el BC que encapsula a Persona y de ahi emitir un evento PersonLastNameChanged y al cual el BC donde vive Pasajero se subscribe, y al recibir este evento, también actualiza el apellido del Pasajero.

A veces es complicado pero si empiezas a mirar a tus BC como micro servicios (de hecho, los micro servicios comenzaron a raiz del concepto de BC), te darás cuenta que tener una instancia de Persona en Pasajero es erróneo. 

Espero haber podido ayudar. 

JF