Duda con la entidad raíz de una agregación
81 views
Skip to first unread message
tolemaC
Dec 20, 2010, 1:14:12 PM12/20/10
to DDD-es
Hola gente,
Llevo poco tiempo estudiando DDD y como no me defiendo muy bien con el
inglés me viene de perlas esta lista.
En mi aplicación hay facturas, dichas facturas tienen una lista de
lineas de factura, también tienen un cliente asociado y un Tipo de
Factura.
Si no me equivoco, la relación que hay entre Facturas y Lineas de
Factura es una composición, La entidad Factura tiene asociadas unas
Lineas de Factura, las lineas son por tanto un agregado a Facturas.
Cliente es otra entidad de mi dominio y no un agregado de la factura;
entre la entidad Cliente y la entidad Factura hay una asociación.
En la agregación de Facturas está la Factura como entidad raíz y las
Lineas de Factura como agregado, Cliente es una asociación externa a
la agregación. Tendré un Repositorio para las Facturas, y a través de
estas accederé a las lineas de factura, nunca accederé a las lineas de
factura si no es a través de una factura.
Mi duda viene con los Tipos de Factura.
Los tipos de factura son dinámicos, el usuario puede crear nuevos
tipos de factura y luego utilizarlos para crear nuevas facturas.
Cuando se crea una factura hay que especificar de que tipo de factura
se trata. Por lo tanto según DDD no tengo muy claro cual es el papel
de Tipo de Factura en la agregación de Facturas ya que en la Entidad
Factura hay una referencia al tipo de Factura, por lo tanto Factura
depende de Tipo de Factura.
Entonces no llego a tener claro cual es la Entidad Raíz en dicha
agregación.
Me he planteado el que Tipo de Factura sea un Value Object de Factura,
pero en mi dominio un tipo de factura tiene su propia identidad. De
hecho para poder crear una factura necesito tener antes un tipo de
factura, al cual debo acceder con un Repositorio, pero según veo en el
esquema de los patrones de Eric Evans a los value objects no se accede
con un repositorio.
He pensado que Tipo de Factura fuera un agregado de Factura, pero ...
sería al contrario ya que la referencia al tipo está en la Factura :/
Por último me queda la duda de si Tipo de Factura es la entidad raíz,
pero ... entonces no le veo sentido, la Entidad importante en mi
dominio es Factura y no Tipo de Factura.
A ver si alguien me puede echar una mano.
Muchas gracias,
Llevo poco tiempo estudiando DDD y como no me defiendo muy bien con el
inglés me viene de perlas esta lista.
En mi aplicación hay facturas, dichas facturas tienen una lista de
lineas de factura, también tienen un cliente asociado y un Tipo de
Factura.
Si no me equivoco, la relación que hay entre Facturas y Lineas de
Factura es una composición, La entidad Factura tiene asociadas unas
Lineas de Factura, las lineas son por tanto un agregado a Facturas.
Cliente es otra entidad de mi dominio y no un agregado de la factura;
entre la entidad Cliente y la entidad Factura hay una asociación.
En la agregación de Facturas está la Factura como entidad raíz y las
Lineas de Factura como agregado, Cliente es una asociación externa a
la agregación. Tendré un Repositorio para las Facturas, y a través de
estas accederé a las lineas de factura, nunca accederé a las lineas de
factura si no es a través de una factura.
Mi duda viene con los Tipos de Factura.
Los tipos de factura son dinámicos, el usuario puede crear nuevos
tipos de factura y luego utilizarlos para crear nuevas facturas.
Cuando se crea una factura hay que especificar de que tipo de factura
se trata. Por lo tanto según DDD no tengo muy claro cual es el papel
de Tipo de Factura en la agregación de Facturas ya que en la Entidad
Factura hay una referencia al tipo de Factura, por lo tanto Factura
depende de Tipo de Factura.
Entonces no llego a tener claro cual es la Entidad Raíz en dicha
agregación.
Me he planteado el que Tipo de Factura sea un Value Object de Factura,
pero en mi dominio un tipo de factura tiene su propia identidad. De
hecho para poder crear una factura necesito tener antes un tipo de
factura, al cual debo acceder con un Repositorio, pero según veo en el
esquema de los patrones de Eric Evans a los value objects no se accede
con un repositorio.
He pensado que Tipo de Factura fuera un agregado de Factura, pero ...
sería al contrario ya que la referencia al tipo está en la Factura :/
Por último me queda la duda de si Tipo de Factura es la entidad raíz,
pero ... entonces no le veo sentido, la Entidad importante en mi
dominio es Factura y no Tipo de Factura.
A ver si alguien me puede echar una mano.
Muchas gracias,
José Manuel Beas
Dec 20, 2010, 3:55:49 PM12/20/10
to ddd...@googlegroups.com
Hola, qué bien que alguien se anima...
Los objetos hacen cosas... ¿qué puede hacer un "Tipo de Factura"? ;-)
tolemaC
Dec 20, 2010, 4:29:41 PM12/20/10
to DDD-es
Necesito el tipo de factura puesto que dependiendo del tipo la factura
la factura se tratará, en ciertos procesos de negocio, de distinto
modo.
Tipo de factura existe por que debo de dar a los usuarios la
posibilidad de clasificar las facturas en grupos que ellos mismos se
pueden crear.
Hmn!!, Sí podría decirse que realmente es una especialización de
Factura.
Tipo de factura puede tener más cosas asociadas, como datos
adicionales, es decir, a un tipo de factura X se le pueden asignar
campos a rellenar en las facturas de dicho tipo.
Si, creo que es una especialización de Factura.
Me gusta que me hayas respondido con preguntas, eso me ayuda a pensar,
pero ... no pillo por donde vas :D
Si es una especialización de factura entonces... debería tener
distintas entidades factura por cada tipo de factura? no me digas
eso :D... no puedo hacer eso.
Los tipos de factura son dinámicos se los crean los usuarios sin que
intervenga el equipo de desarrollo...
Los usuarios asignan cosas a los tipos de factura que luego afectan a
cada factura de dicho tipo.
Me quedo intrigado :)
Sigo pensando, pero no lo pillo :/
la factura se tratará, en ciertos procesos de negocio, de distinto
modo.
Tipo de factura existe por que debo de dar a los usuarios la
posibilidad de clasificar las facturas en grupos que ellos mismos se
pueden crear.
Hmn!!, Sí podría decirse que realmente es una especialización de
Factura.
Tipo de factura puede tener más cosas asociadas, como datos
adicionales, es decir, a un tipo de factura X se le pueden asignar
campos a rellenar en las facturas de dicho tipo.
Si, creo que es una especialización de Factura.
Me gusta que me hayas respondido con preguntas, eso me ayuda a pensar,
pero ... no pillo por donde vas :D
Si es una especialización de factura entonces... debería tener
distintas entidades factura por cada tipo de factura? no me digas
eso :D... no puedo hacer eso.
Los tipos de factura son dinámicos se los crean los usuarios sin que
intervenga el equipo de desarrollo...
Los usuarios asignan cosas a los tipos de factura que luego afectan a
cada factura de dicho tipo.
Me quedo intrigado :)
Sigo pensando, pero no lo pillo :/
José Manuel Beas
Dec 20, 2010, 4:37:25 PM12/20/10
to ddd...@googlegroups.com
Ja, ja... si te gusta te daré más preguntas...
Un saludo,
Jose Manuel Beas
¿Cómo modelarías Coches, Motocicletas, Camiones? ¿Hablarías de un Tipo de Vehículo?
Piensa en la responsabilidad de un objeto llamado "Tipo de Vehículo"? ¿Qué puede hacer un Tipo de Vehículo?
;-)
Un saludo,
Jose Manuel Beas
Angel Java Lopez
Dec 20, 2010, 4:42:13 PM12/20/10
to ddd...@googlegroups.com
Hola gente!
Hmmm.... Recuerdo tu .txt sobre el framework dinamico que habian desarrollado (lo lei en otra lista, no se si lo habias presentado aca).
Entiendo que quieres que siga dinamico.
Por lo que entendi, los usuarios pueden definir nuevos tipos de factura, no solo como si fuera una nueva provincia (codigo y descripcion) sino que pueden agregarle campos a esos nuevos tipos de facturas.
Pregunta: pero nunca les paso que no basta solo eso? Como solucionan el tema: para la Factura tipo X, el IVA se calcula de otra forma? O cosas asi, temas de negocio que cambian.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Hmmm.... Recuerdo tu .txt sobre el framework dinamico que habian desarrollado (lo lei en otra lista, no se si lo habias presentado aca).
Entiendo que quieres que siga dinamico.
Por lo que entendi, los usuarios pueden definir nuevos tipos de factura, no solo como si fuera una nueva provincia (codigo y descripcion) sino que pueden agregarle campos a esos nuevos tipos de facturas.
Pregunta: pero nunca les paso que no basta solo eso? Como solucionan el tema: para la Factura tipo X, el IVA se calcula de otra forma? O cosas asi, temas de negocio que cambian.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
2010/12/20 tolemaC <tol...@gmail.com>
--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a ddd...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a ddd-es+un...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/ddd-es?hl=es.
tolemaC
Dec 20, 2010, 5:19:45 PM12/20/10
to DDD-es
Juan Manuel, lo de las motos, coches, camiones, ... depende de lo que
se requiera.
Por ejemplo si tuviera que mantener una flota de vehículos en el que
hay distintos tipos y pueden crecer al día de mañana pensaría que
necesito saber de esos nuevos tipos de vehiculos.
Por ejemplo puedo tener una entidad Vehículo, y cada uno de los
vehículos tendría un TipoVehiculo, en TipoVehiculos tendría
propiedades como Número de ruedas, cilindrada máxima/mínima, tipo de
impuestos a pagar a hacienda, ... lo que necesitara para poder
realizar las operaciones de negocio sobre los vehiculos y leer los
datos variantes de su tipo.
Angel, uno de las propiedades que hay en el TipoFactura es el IVA que
se le aplica. Otra propiedad es el destino analítico o código de
imputación para relacionar la factura con un departamento en concreto.
Cada tipo de entidad puede tener unos campos determinados, dependerá
de la entidad.
En general, muchas de las entidades de mi negocio tienen tipo,
dependiendo de que entidad se trata tienen más o menos propiedades,
pero en general todas las entidades que tienen tipo tienen la
posibilidad de asignarle valores adicionales a las entidades.
Por ejemplo: cuando se crea un TipoFactura X, puedo decirle que tiene
dos propiedades adicionales PropiedadA y PropiedadB, de forma que al
crear una Factura con de TipoFactura X es posible asignarle valores a
las propiedades A y B, sin embargo una factura de tipo Y no tendría
esas propiedades A y B, pero si pueden tener otras.
Otro caso más especifico son los expedientes. Un expediente
urbanístico tiene asignado un responsable del ayuntamiento. Un
expediente por impago de un cliente tiene asignado un importe deudor,
son características adicionales que dependen del tipo del expediente.
Todos los expedientes son tratados igual excepto algunas cosas que
vienen dadas por el Tipo.
Por si sirve de algo pongo aquí el texto al que hace referencia Angel:
http://jros.org/files/orm/parrafada.txt
Releyendo lo que he escrito he visto que puede ser confuso. Por un
lado está el Tipo y por otro la Entidad, pongo ejemplos para aclarar:
Factura: Cliente, ImporteTotal, Fecha, Numero, TipoFactura,
ListaValoresAdicionales
TipoFactura: Nombre, Descripción, PorcentageIvaAplicar,
DestinoAnalitico, ListaPropiedadesAdicionales
Expediente: Nombre, Descripción, TipoExpediente,
ListaValoresAdicionales
TipoExpediente: Nombre, Descripción, ListaPropiedadesAdicionales
ListaPropiedadesAdicionales es un IList<String> y
ListaValoresAdicionales es un Dictionary<string, string>
Las facturas y Expedientes tendrán tantos valores adicionales como
propiedades adicionales tenga el tipo.
Para mi es lo más normal del mundo, tanto como para vosotros raro.
Saludos y mil gracias,
On 20 dic, 22:42, Angel Java Lopez <ajlopez2...@gmail.com> wrote:
> Hola gente!
>
> Hmmm.... Recuerdo tu .txt sobre el framework dinamico que habian
> desarrollado (lo lei en otra lista, no se si lo habias presentado aca).
>
> Entiendo que quieres que siga dinamico.
>
> Por lo que entendi, los usuarios pueden definir nuevos tipos de factura, no
> solo como si fuera una nueva provincia (codigo y descripcion) sino que
> pueden agregarle campos a esos nuevos tipos de facturas.
>
> Pregunta: pero nunca les paso que no basta solo eso? Como solucionan el
> tema: para la Factura tipo X, el IVA se calcula de otra forma? O cosas asi,
> temas de negocio que cambian.
>
> Nos leemos!
>
> Angel "Java" Lopezhttp://www.ajlopez.comhttp://twitter.com/ajlopez
>
> 2010/12/20 tolemaC <tole...@gmail.com>
> > ddd-es+un...@googlegroups.com<ddd-es%2Bunsu...@googlegroups.com>
se requiera.
Por ejemplo si tuviera que mantener una flota de vehículos en el que
hay distintos tipos y pueden crecer al día de mañana pensaría que
necesito saber de esos nuevos tipos de vehiculos.
Por ejemplo puedo tener una entidad Vehículo, y cada uno de los
vehículos tendría un TipoVehiculo, en TipoVehiculos tendría
propiedades como Número de ruedas, cilindrada máxima/mínima, tipo de
impuestos a pagar a hacienda, ... lo que necesitara para poder
realizar las operaciones de negocio sobre los vehiculos y leer los
datos variantes de su tipo.
Angel, uno de las propiedades que hay en el TipoFactura es el IVA que
se le aplica. Otra propiedad es el destino analítico o código de
imputación para relacionar la factura con un departamento en concreto.
Cada tipo de entidad puede tener unos campos determinados, dependerá
de la entidad.
En general, muchas de las entidades de mi negocio tienen tipo,
dependiendo de que entidad se trata tienen más o menos propiedades,
pero en general todas las entidades que tienen tipo tienen la
posibilidad de asignarle valores adicionales a las entidades.
Por ejemplo: cuando se crea un TipoFactura X, puedo decirle que tiene
dos propiedades adicionales PropiedadA y PropiedadB, de forma que al
crear una Factura con de TipoFactura X es posible asignarle valores a
las propiedades A y B, sin embargo una factura de tipo Y no tendría
esas propiedades A y B, pero si pueden tener otras.
Otro caso más especifico son los expedientes. Un expediente
urbanístico tiene asignado un responsable del ayuntamiento. Un
expediente por impago de un cliente tiene asignado un importe deudor,
son características adicionales que dependen del tipo del expediente.
Todos los expedientes son tratados igual excepto algunas cosas que
vienen dadas por el Tipo.
Por si sirve de algo pongo aquí el texto al que hace referencia Angel:
http://jros.org/files/orm/parrafada.txt
Releyendo lo que he escrito he visto que puede ser confuso. Por un
lado está el Tipo y por otro la Entidad, pongo ejemplos para aclarar:
Factura: Cliente, ImporteTotal, Fecha, Numero, TipoFactura,
ListaValoresAdicionales
TipoFactura: Nombre, Descripción, PorcentageIvaAplicar,
DestinoAnalitico, ListaPropiedadesAdicionales
Expediente: Nombre, Descripción, TipoExpediente,
ListaValoresAdicionales
TipoExpediente: Nombre, Descripción, ListaPropiedadesAdicionales
ListaPropiedadesAdicionales es un IList<String> y
ListaValoresAdicionales es un Dictionary<string, string>
Las facturas y Expedientes tendrán tantos valores adicionales como
propiedades adicionales tenga el tipo.
Para mi es lo más normal del mundo, tanto como para vosotros raro.
Saludos y mil gracias,
On 20 dic, 22:42, Angel Java Lopez <ajlopez2...@gmail.com> wrote:
> Hola gente!
>
> Hmmm.... Recuerdo tu .txt sobre el framework dinamico que habian
> desarrollado (lo lei en otra lista, no se si lo habias presentado aca).
>
> Entiendo que quieres que siga dinamico.
>
> Por lo que entendi, los usuarios pueden definir nuevos tipos de factura, no
> solo como si fuera una nueva provincia (codigo y descripcion) sino que
> pueden agregarle campos a esos nuevos tipos de facturas.
>
> Pregunta: pero nunca les paso que no basta solo eso? Como solucionan el
> tema: para la Factura tipo X, el IVA se calcula de otra forma? O cosas asi,
> temas de negocio que cambian.
>
> Nos leemos!
>
> Angel "Java" Lopezhttp://www.ajlopez.comhttp://twitter.com/ajlopez
>
tolemaC
Dec 20, 2010, 5:24:11 PM12/20/10
to DDD-es
Estoy pensando que estos Tipos de Factura no pueden ser agregados de
las Facturas, supongo que serán entidades fuera de la agregación de
facturas con una asociación a la entidad factura. O más bien la
Entidad Factura tiene una asociación con el Tipo de Factura. Al igual
que una factura tiene una asociación con un cliente.
No se, supongo que esa será la única forma de encajar en DDD.
las Facturas, supongo que serán entidades fuera de la agregación de
facturas con una asociación a la entidad factura. O más bien la
Entidad Factura tiene una asociación con el Tipo de Factura. Al igual
que una factura tiene una asociación con un cliente.
No se, supongo que esa será la única forma de encajar en DDD.
tolemaC
Dec 20, 2010, 5:32:43 PM12/20/10
to DDD-es
Más datos ;)
En casi todos los casos tenemos seguridad por Tipo de entidad.
Por ejemplo para las Tareas. Existe una Entidad Tarea, que tiene Tipo.
Tarea y TareaTipo, es posible asignarle perfiles a los tipos diciendo
si pueden leer, crear, modificar o lo que sea, Tareas de cierto tipo.
Lo bueno de esto es que el usuario se crea el tipo de tarea y luego
asigna seguridad a su gente.
Por ejemplo el jefe de desarrollo crea un tipo de tarea A, le asigna
permisos a Juan, Pepe y Álvaro para que solo ellos puedan ver dichas
tareas. Luego crea tareas del tipo A y las va asignando. Nadie excepto
los administradores pueden ver esas tareas.
Y claro, lo bueno de todo esto es que el equipo de desarrollo no
interviene, no hay que modificar el código. Es cómodo para nosotros
nos permite mucha flexibilidad.
En el documento que he puesto antes hay más detalles, pienso que es
interesante de leer aunque un poco largo.
En casi todos los casos tenemos seguridad por Tipo de entidad.
Por ejemplo para las Tareas. Existe una Entidad Tarea, que tiene Tipo.
Tarea y TareaTipo, es posible asignarle perfiles a los tipos diciendo
si pueden leer, crear, modificar o lo que sea, Tareas de cierto tipo.
Lo bueno de esto es que el usuario se crea el tipo de tarea y luego
asigna seguridad a su gente.
Por ejemplo el jefe de desarrollo crea un tipo de tarea A, le asigna
permisos a Juan, Pepe y Álvaro para que solo ellos puedan ver dichas
tareas. Luego crea tareas del tipo A y las va asignando. Nadie excepto
los administradores pueden ver esas tareas.
Y claro, lo bueno de todo esto es que el equipo de desarrollo no
interviene, no hay que modificar el código. Es cómodo para nosotros
nos permite mucha flexibilidad.
En el documento que he puesto antes hay más detalles, pienso que es
interesante de leer aunque un poco largo.
José Manuel Beas
Dec 20, 2010, 5:59:14 PM12/20/10
to ddd-es
Vaya, mucha información... en mi respuesta no había puesto atención al detalle de que tu "Tipo de Factura" es dinámica. Entiendo, por tanto, que es una cualidad (o conjunto de cualidades) de la factura y no exactamente una especialización de la misma. No sé cómo lo ves, pero para mi es algo así como un patrón Strategy que puedes configurar. Esto quizás se aparta un poco de DDD, sin dejar de ser un ejercicio interesante, y quizás la mayor dificultad se puede encontrar a la hora de encontrar el lenguaje ubícuo puesto que, realmente, no parece que estés resolviendo el problema de las facturas sino el de un framework de propósito más general. Quizás deberíamos explorar ese territorio que comentas en http://jros.org/files/orm/parrafada.txt y trabajar en el terreno de las "entidades", "tareas", etc.
Un saludo,
Jose Manuel Beas
Otra opción (la que yo tomaría a primera vista) sería la de explorar tu verdadero problema, el de los Expedientes, Presupuestos, Documentos, Tareas, Maquinaria, ... y dejar que el framework (si puede haber alguno) que emerja a partir de ahí y no al revés (imponiéndolo).
No sé cómo lo véis los demás.
Un saludo,
Jose Manuel Beas
tolemaC
Dec 20, 2010, 6:18:20 PM12/20/10
to DDD-es
Si José Manuel, la idea es esa, al principio quería imponerlo, pero he
tenido que cambiar el chip para cambiar mi forma de pensar, intento
resolver los problemas finales en mis entidades de negocio, pero a la
vez que voy enfrentandome a ellas intento extraer lo común para otras
entidades de negocio y abtrayendolas en clases base.
Mi mayor problema es olvidarme de lo que sé para buscar nuevas
soluciones, el hablarlo con otras personas que piensan distinto me
ayuda a pensar de otro modo. La mayoría de las soluciones las
encuentro haciendome preguntas que nunca me haría, por eso me gustó
que tu me preguntaras, muchas veces la solución a mis problemas están
en un replanteamiento desde cero y para eso me sirven preguntas
básicas.
Mi idea es que las Entidades de mi Dominio tengan un comportamiento
común, para ello estoy usando herencia, esto me lleva a crearme una
especie de "sub-infraestructura" en mi propio dominio.
No se, no se, ... estoy intentando dar con un caso en la vida real
donde se de que en un dominio una entidad raíz de una agregación
dependa exhaustivamente de otra entidad raíz.
Saludos,
On 20 dic, 23:59, José Manuel Beas <jose.m.b...@gmail.com> wrote:
> Vaya, mucha información... en mi respuesta no había puesto atención al
> detalle de que tu "Tipo de Factura" es dinámica. Entiendo, por tanto, que es
> una cualidad (o conjunto de cualidades) de la factura y no exactamente una
> especialización de la misma. No sé cómo lo ves, pero para mi es algo así
> como un patrón Strategy que puedes configurar. Esto quizás se aparta un poco
> de DDD, sin dejar de ser un ejercicio interesante, y quizás la mayor
> dificultad se puede encontrar a la hora de encontrar el lenguaje ubícuo
> puesto que, realmente, no parece que estés resolviendo el problema de las
> facturas sino el de un framework de propósito más general. Quizás deberíamos
> explorar ese territorio que comentas enhttp://jros.org/files/orm/parrafada.txty trabajar en el terreno de las
tenido que cambiar el chip para cambiar mi forma de pensar, intento
resolver los problemas finales en mis entidades de negocio, pero a la
vez que voy enfrentandome a ellas intento extraer lo común para otras
entidades de negocio y abtrayendolas en clases base.
Mi mayor problema es olvidarme de lo que sé para buscar nuevas
soluciones, el hablarlo con otras personas que piensan distinto me
ayuda a pensar de otro modo. La mayoría de las soluciones las
encuentro haciendome preguntas que nunca me haría, por eso me gustó
que tu me preguntaras, muchas veces la solución a mis problemas están
en un replanteamiento desde cero y para eso me sirven preguntas
básicas.
Mi idea es que las Entidades de mi Dominio tengan un comportamiento
común, para ello estoy usando herencia, esto me lleva a crearme una
especie de "sub-infraestructura" en mi propio dominio.
No se, no se, ... estoy intentando dar con un caso en la vida real
donde se de que en un dominio una entidad raíz de una agregación
dependa exhaustivamente de otra entidad raíz.
Saludos,
On 20 dic, 23:59, José Manuel Beas <jose.m.b...@gmail.com> wrote:
> Vaya, mucha información... en mi respuesta no había puesto atención al
> detalle de que tu "Tipo de Factura" es dinámica. Entiendo, por tanto, que es
> una cualidad (o conjunto de cualidades) de la factura y no exactamente una
> especialización de la misma. No sé cómo lo ves, pero para mi es algo así
> como un patrón Strategy que puedes configurar. Esto quizás se aparta un poco
> de DDD, sin dejar de ser un ejercicio interesante, y quizás la mayor
> dificultad se puede encontrar a la hora de encontrar el lenguaje ubícuo
> puesto que, realmente, no parece que estés resolviendo el problema de las
> facturas sino el de un framework de propósito más general. Quizás deberíamos
tolemaC
Dec 20, 2010, 6:25:00 PM12/20/10
to DDD-es
Se me ocurre...
Imaginemos un programa de contabilidad que sea capaz de llevar la
contabilidad de varias empresas y haya un almacén (gestión de Stock)
común a todas las empresas.
Tendríamos una Entidad Empresa a la cual le asociamos Facturas.
En la agregación de Facturas estaría la Entidad Raíz "Factura" y el
agregado "LineaFactura". Factura tendría una asociación con Empresa,
sin ser Factura agregado de Empresa.
Sin embargo el agregado LineaFactura tendría una asociación con los
productos del almacén y dichos productos de almacén no estarían para
nada ligados a la empresa que Factura.
Que papel jugaría Empresa en el Dominio ya que solo influye en la
facturación?
A lo que voy es que quizá mi FacturaTipo sea una Entidad solitaria que
tan solo sirve para relacionarla con Factura.
No se adapta mucho el símil pero ... creo que es la única solución que
viable.
Saludos y gracias,
> > explorar ese territorio que comentas enhttp://jros.org/files/orm/parrafada.txtytrabajar en el terreno de las
Imaginemos un programa de contabilidad que sea capaz de llevar la
contabilidad de varias empresas y haya un almacén (gestión de Stock)
común a todas las empresas.
Tendríamos una Entidad Empresa a la cual le asociamos Facturas.
En la agregación de Facturas estaría la Entidad Raíz "Factura" y el
agregado "LineaFactura". Factura tendría una asociación con Empresa,
sin ser Factura agregado de Empresa.
Sin embargo el agregado LineaFactura tendría una asociación con los
productos del almacén y dichos productos de almacén no estarían para
nada ligados a la empresa que Factura.
Que papel jugaría Empresa en el Dominio ya que solo influye en la
facturación?
A lo que voy es que quizá mi FacturaTipo sea una Entidad solitaria que
tan solo sirve para relacionarla con Factura.
No se adapta mucho el símil pero ... creo que es la única solución que
viable.
Saludos y gracias,
José Manuel Beas
Dec 20, 2010, 6:35:42 PM12/20/10
to ddd-es
Yo, en este último ejemplo, veo varios dominios: el de las facturas, el de los clientes (algunos empresas, otros personas...). Pero quizás esté demasiado influido por una visión más bien SOA (donde el servicio de facturas sólo conoce a los clientes por referencia y viceversa).
Si intento verlo todo como un único dominio me siguen saliendo como agregaciones bien diferentes. Cada uno con su vida propia. Pero intuyo que tu problema no va por ahí sino por "los tipos de factura". Y volvemos (casi) al principio de la conversación. Si puedes pensar en los tipos de factura como "strategies", realmente no son entidades (en el sentido de DDD) sino "algoritmos" que puedes usar para cambiar el comportamiento de tus facturas. Pero me sigue dando en la nariz que estás tratando de imponer el framework y no dejarlo emerger. ¿Has probado a listar todos los tipos diferentes de facturas y ver qué tienen en común entre ellas? No sólo en lo estructural sino también en su comportamiento. De ahí probablemente te salgan un montón de ValueObjects, de Especificaciones y de Políticas (Specifications y Policies en el libro de Evans). Pero vamos, que sólo es una cuestión de "olor". ;-)
¡Suerte! Y a ver si se anima alguien más a comentar. :-)
Un saludo,
Jose Manuel Beas
Jose Manuel Beas
Carlos Peix
Dec 21, 2010, 7:15:00 AM12/21/10
to ddd-es
Hola,
Vuelvo a tu consulta original, aunque la discusion lateral sobre DDD esta bien interesante tambien.
Cuando tengo dudas sobre la composicion de una agregacion, sobre cuales son sus limites, utilizo el concepto del ciclo de vida. En tu caso, la agregacion factura e items factura tienen el mismo ciclo de vida, nacen juntos, se graban juntos, se eliminarian juntos.
Esto indica que tienen el mismo ciclo de vida. Nadie dejaria en el sistema los items de una factura sin su factura.
El tipo de factura probablemente no se elimine del sistema cuando se elimina una factura que lo referencia. Creo que el hecho de que el usuario lo cree ante la necesidad es una cuestion accidental, lo mismo podria pasar con el cliente.
Un saludo.
--
Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a ddd...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a ddd-es+un...@googlegroups.com
Angel Java Lopez
Dec 21, 2010, 8:38:32 AM12/21/10
to ddd...@googlegroups.com
Hola gente!
No veo que sea raro. Aca en Argentina he visto implementaciones dinamicas, parecidas a las que planteas... Pero a ver.
Hmmm... sigo sin ver como resuelven el tema. Ahi mencionas que "el IVA que se le aplica". Pero que pasa si maniana aparece una forma de aplicar el IVA que depende de la cantidad de renglones de la factura? A lo que voy es: nunca se toparon con metodos de negocio que tuvieron que agregar ante una nueva situacion?
Otro ejemplo: aca en Argentina, hubo un tiempo que el aguinaldo (plus sobre el precio a fin de anio) paso a ser liquidado dos veces (una a mitad de anio) y tambien a ser liquidado proporcional (a los dias trabajados). En tu framework, como hubieran solucionado el cambio?
Pregunto, porque en esos casos, estoy explorando que el usuario pueda definir nuevos metodos, no solo propiedades (de ahi, una de las razones de mi exploracion de un lenguaje dinamico como AjSharp).
No veo que sea raro. Aca en Argentina he visto implementaciones dinamicas, parecidas a las que planteas... Pero a ver.
Angel, uno de las propiedades que hay en el TipoFactura es el IVA que
se le aplica. Otra propiedad es el destino analítico o código de
imputación para relacionar la factura con un departamento en concreto.
se le aplica. Otra propiedad es el destino analítico o código de
imputación para relacionar la factura con un departamento en concreto.
Otro ejemplo: aca en Argentina, hubo un tiempo que el aguinaldo (plus sobre el precio a fin de anio) paso a ser liquidado dos veces (una a mitad de anio) y tambien a ser liquidado proporcional (a los dias trabajados). En tu framework, como hubieran solucionado el cambio?
Pregunto, porque en esos casos, estoy explorando que el usuario pueda definir nuevos metodos, no solo propiedades (de ahi, una de las razones de mi exploracion de un lenguaje dinamico como AjSharp).
2010/12/20 tolemaC <tol...@gmail.com>
Juan Manuel, lo de las motos, coches, camiones, ... depende de lo que
Edgar Ramos
Dec 21, 2010, 8:54:38 AM12/21/10
to ddd...@googlegroups.com
Angel por aca (Ecuador), justamente en el POS que estoy terminando, el iva se aplica por renglon de la linea es decir, y hay otro impuesto que tambien se aplica de la misma manera.
Hay cierto productos de la linea de factura que aplican iva y otros no, y estos mismos productos aplican servicio o no (otro impuesto)
Saludos
Edgar
Hay cierto productos de la linea de factura que aplican iva y otros no, y estos mismos productos aplican servicio o no (otro impuesto)
Saludos
Edgar
tolemaC
Dec 21, 2010, 9:00:27 AM12/21/10
to DDD-es
:)
Angel, si hay algo que tenemos que tocar se toca, no hay problema.
Aquí hacemos algo parecido a lo que dices. Cada entidad tiene unas
acciones asociadas que se lanzan en un momento determinado.
Una entidad tiene "eventos" y esos eventos ejecutan acciones.
Por lo tanto yo puedo asignarle una acción a un evento cualquiera. Los
eventos son Antes y Despues de: crear, modificar, transitar estado,
eliminar, ...
Estas acciones son en realidad metodos C# que invocamos por reflexión.
Cada acción tiene asociado un assembly, una clase y un método.
Con estas herramientas se pueden hacer muchas cosas, pero en el caso
de que haya que tocar el nucleo se toca.
Es un framework propio, pero no cerrado. El objetivo es ahorrar
trabajo, pero si hay que trabajar se trabaja :)
Saludos,
> > <ddd-es%2Bunsu...@googlegroups.com<ddd-es%252Bunsubscribe@googlegroups. com>
Angel, si hay algo que tenemos que tocar se toca, no hay problema.
Aquí hacemos algo parecido a lo que dices. Cada entidad tiene unas
acciones asociadas que se lanzan en un momento determinado.
Una entidad tiene "eventos" y esos eventos ejecutan acciones.
Por lo tanto yo puedo asignarle una acción a un evento cualquiera. Los
eventos son Antes y Despues de: crear, modificar, transitar estado,
eliminar, ...
Estas acciones son en realidad metodos C# que invocamos por reflexión.
Cada acción tiene asociado un assembly, una clase y un método.
Con estas herramientas se pueden hacer muchas cosas, pero en el caso
de que haya que tocar el nucleo se toca.
Es un framework propio, pero no cerrado. El objetivo es ahorrar
trabajo, pero si hay que trabajar se trabaja :)
Saludos,
> No veo que sea raro. Aca en Argentina he visto implementaciones dinamicas,
> parecidas a las que planteas... Pero a ver.
>
> Angel, uno de las propiedades que hay en el TipoFactura es el IVA que
> se le aplica. Otra propiedad es el destino analítico o código de
> imputación para relacionar la factura con un departamento en concreto.
>
> Hmmm... sigo sin ver como resuelven el tema. Ahi mencionas que "el IVA que
> se le aplica". Pero que pasa si maniana aparece una forma de aplicar el IVA
> que depende de la cantidad de renglones de la factura? A lo que voy es:
> nunca se toparon con metodos de negocio que tuvieron que agregar ante una
> nueva situacion?
>
> Otro ejemplo: aca en Argentina, hubo un tiempo que el aguinaldo (plus sobre
> el precio a fin de anio) paso a ser liquidado dos veces (una a mitad de
> anio) y tambien a ser liquidado proporcional (a los dias trabajados). En tu
> framework, como hubieran solucionado el cambio?
>
> Pregunto, porque en esos casos, estoy explorando que el usuario pueda
> definir nuevos metodos, no solo propiedades (de ahi, una de las razones de
> mi exploracion de un lenguaje dinamico como AjSharp).
>
> Nos leemos!
>
> parecidas a las que planteas... Pero a ver.
>
> Angel, uno de las propiedades que hay en el TipoFactura es el IVA que
> se le aplica. Otra propiedad es el destino analítico o código de
> imputación para relacionar la factura con un departamento en concreto.
>
> Hmmm... sigo sin ver como resuelven el tema. Ahi mencionas que "el IVA que
> se le aplica". Pero que pasa si maniana aparece una forma de aplicar el IVA
> que depende de la cantidad de renglones de la factura? A lo que voy es:
> nunca se toparon con metodos de negocio que tuvieron que agregar ante una
> nueva situacion?
>
> Otro ejemplo: aca en Argentina, hubo un tiempo que el aguinaldo (plus sobre
> el precio a fin de anio) paso a ser liquidado dos veces (una a mitad de
> anio) y tambien a ser liquidado proporcional (a los dias trabajados). En tu
> framework, como hubieran solucionado el cambio?
>
> Pregunto, porque en esos casos, estoy explorando que el usuario pueda
> definir nuevos metodos, no solo propiedades (de ahi, una de las razones de
> mi exploracion de un lenguaje dinamico como AjSharp).
>
> Nos leemos!
>
Angel Java Lopez
Dec 21, 2010, 9:08:11 AM12/21/10
to ddd...@googlegroups.com
Ah! Bien!
Gracias por la info. Ahora me queda mas claro...
Los puntos de extensibilidad los tienen ya determinados. Y los extienden por codigo compilado.
No les convendria tener la capacidad de que el usuario/analista de la empresa final pueda definir que ejecutar en esos puntos? De la misma forma en que define nuevos tipos de entidad/propiedades.
Hmmm... podria escribir un code kata de eso ;-) ;-)
Gracias por la info. Ahora me queda mas claro...
Los puntos de extensibilidad los tienen ya determinados. Y los extienden por codigo compilado.
No les convendria tener la capacidad de que el usuario/analista de la empresa final pueda definir que ejecutar en esos puntos? De la misma forma en que define nuevos tipos de entidad/propiedades.
Hmmm... podria escribir un code kata de eso ;-) ;-)
2010/12/21 tolemaC <tol...@gmail.com>
tolemaC
Dec 21, 2010, 1:02:04 PM12/21/10
to DDD-es
No se lo que es un code kata :/
La empresa final somos nosotros. Lo que hacemos es intentar que cada
acción añadida al sistema sea lo más atómica y genérica posible de
forma que nos sirva para más cosas, de esta forma llegamos a tener una
batería de acciones bastante extensa. El usuario final es libre de
añadir acciones a sus entidades y eventos de estas. El usuario puede
definir que acciones ejecutar.
Lo que no puede hacer es crear acciones, tendría que programar en .NET
crear el assembly y conocer el convenio de parámetros que usamos y
tener acceso al directorio de publicación de la aplicación.
Por supuesto muy pocos usuarios tienen permiso de modificación de
acciones a ejecutar, solo el responsable de la información mantenida,
el dueño de la información; Que para nada somos nosotros.
On 21 dic, 15:08, Angel Java Lopez <ajlopez2...@gmail.com> wrote:
> Ah! Bien!
>
> Gracias por la info. Ahora me queda mas claro...
>
> Los puntos de extensibilidad los tienen ya determinados. Y los extienden por
> codigo compilado.
>
> No les convendria tener la capacidad de que el usuario/analista de la
> empresa final pueda definir que ejecutar en esos puntos? De la misma forma
> en que define nuevos tipos de entidad/propiedades.
>
> Hmmm... podria escribir un code kata de eso ;-) ;-)
>
> Nos leemos!
>
> Angel "Java" Lopezhttp://www.ajlopez.comhttp://twitter.com/ajlopez
>
> 2010/12/21 tolemaC <tole...@gmail.com>
> > > > <ddd-es%2Bunsu...@googlegroups.com<ddd-es%252Bunsubscribe@googlegroups. com>
>
> leer más »
La empresa final somos nosotros. Lo que hacemos es intentar que cada
acción añadida al sistema sea lo más atómica y genérica posible de
forma que nos sirva para más cosas, de esta forma llegamos a tener una
batería de acciones bastante extensa. El usuario final es libre de
añadir acciones a sus entidades y eventos de estas. El usuario puede
definir que acciones ejecutar.
Lo que no puede hacer es crear acciones, tendría que programar en .NET
crear el assembly y conocer el convenio de parámetros que usamos y
tener acceso al directorio de publicación de la aplicación.
Por supuesto muy pocos usuarios tienen permiso de modificación de
acciones a ejecutar, solo el responsable de la información mantenida,
el dueño de la información; Que para nada somos nosotros.
On 21 dic, 15:08, Angel Java Lopez <ajlopez2...@gmail.com> wrote:
> Ah! Bien!
>
> Gracias por la info. Ahora me queda mas claro...
>
> Los puntos de extensibilidad los tienen ya determinados. Y los extienden por
> codigo compilado.
>
> No les convendria tener la capacidad de que el usuario/analista de la
> empresa final pueda definir que ejecutar en esos puntos? De la misma forma
> en que define nuevos tipos de entidad/propiedades.
>
> Hmmm... podria escribir un code kata de eso ;-) ;-)
>
> Nos leemos!
>
> Angel "Java" Lopezhttp://www.ajlopez.comhttp://twitter.com/ajlopez
>
> > <ddd-es%252Bunsubscribe@googlegroups. com>
>
> > > > > > Para tener acceso a más opciones, visita el grupo en
> > > > > >http://groups.google.com/group/ddd-es?hl=es.
>
> > > > --
> > > > Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de
> > Grupos
> > > > de Google.
> > > > Para publicar una entrada en este grupo, envía un correo electrónico a
> > > > ddd...@googlegroups.com.
> > > > Para anular tu suscripción a este grupo, envía un correo electrónico a
> > > > ddd-es+un...@googlegroups.com<ddd-es%2Bunsu...@googlegroups.com>
>
> ...
>
> > > > > > Para tener acceso a más opciones, visita el grupo en
> > > > > >http://groups.google.com/group/ddd-es?hl=es.
>
> > > > --
> > > > Has recibido este mensaje porque estás suscrito al grupo "DDD-es" de
> > Grupos
> > > > de Google.
> > > > Para publicar una entrada en este grupo, envía un correo electrónico a
> > > > ddd...@googlegroups.com.
> > > > Para anular tu suscripción a este grupo, envía un correo electrónico a
> > > > ddd-es+un...@googlegroups.com<ddd-es%2Bunsu...@googlegroups.com>
>
>
> leer más »
Angel Java Lopez
Dec 21, 2010, 1:19:21 PM12/21/10
to ddd...@googlegroups.com
Hola gente!
Ah! Code Kata es
http://codekata.pragprog.com/
Algunos enlaces
http://delicious.com/ajlopez/codekata con ideas y ejemplos
Bien, un dato que se me habia pasado: "la empresa final somos nosotros". Los casos que conozco en Argentina, son "la empresa final son nuestros clientes", y entonces, cada cliente tiene sus extensiones de entidades y demas, y esa descripcion, como creo entendi en tu framework, esta guardada en la base. La empresa desarrolladora cambia los ejecutables, pero hasta algunas acciones/puntos de extensibilidad los tienen en el cliente final, en base de datos de cada empresa final (usan Visual Fox y pueden interpretar codigo desde la base). No agregan acciones particulares nuevas para un cliente final, porque tendrian que recordar: "esta accion la agregue para el cliente C1, y esta otra para el cliente C2".
No todo eso lo han logrado hacer en los dos casos que conozco, (yo tampoco lo vi en detalle hasta donde llegaron) pero queria comentar lo que vi que se parecia a lo que estan haciendo uds.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
Ah! Code Kata es
http://codekata.pragprog.com/
Algunos enlaces
http://delicious.com/ajlopez/codekata con ideas y ejemplos
Bien, un dato que se me habia pasado: "la empresa final somos nosotros". Los casos que conozco en Argentina, son "la empresa final son nuestros clientes", y entonces, cada cliente tiene sus extensiones de entidades y demas, y esa descripcion, como creo entendi en tu framework, esta guardada en la base. La empresa desarrolladora cambia los ejecutables, pero hasta algunas acciones/puntos de extensibilidad los tienen en el cliente final, en base de datos de cada empresa final (usan Visual Fox y pueden interpretar codigo desde la base). No agregan acciones particulares nuevas para un cliente final, porque tendrian que recordar: "esta accion la agregue para el cliente C1, y esta otra para el cliente C2".
No todo eso lo han logrado hacer en los dos casos que conozco, (yo tampoco lo vi en detalle hasta donde llegaron) pero queria comentar lo que vi que se parecia a lo que estan haciendo uds.
Nos leemos!
Angel "Java" Lopez
http://twitter.com/ajlopez
Reply all
Reply to author
Forward
0 new messages