Hola Leandro,
 
Deje este mail en espera unos dias, ahora lo rescato.
 
Lo primero que deberia quedar claro es que estos son servicios del dominio. Esto es, objetos cuya responsabilidad es prestar un servicio (no confundir con la acepcion mas cercana a la fachada de negocios o al transaction script).
 
Tal como vos decis, el tema es si el servicio o la operacion es stateless. Evans dice claramente que la operacion es stateless y es asi como debe ser. El servicio no es stateless.
 
Tal como vos sugeris, la configuracion del servicio es un tema importante y muchas veces lo define el usuario. En mi caso uso esto para definir eventos en algunos modelos. Cuando un evento se aplica lo hace en forma stateless, pero el servicio en si tiene estado. Tengo una tabla en la aplicacion que almacena los eventos y el usuario ingresa a modificar los eventos (en algunas de sus propiedades).
 
Una punta para los eventos de que hablo son los DomainEvents, tal como los define Fowler
 
Saludos
 
Carlos


From: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Leandro Tuttini
Sent: Domingo, 24 de Septiembre de 2006 09:18 p.m.
To: patrones List Member
Subject: !-> [patrones] Domain Model - Domain Service y el repositorio

Carlos, muchas gracias, creo que es un tema que ayudara a entender un poco mas en profundidad la implementacion de al menos uno de los componentes del domain model.
 
De paso aprovecho para realizar una pregunta sobre este mismo tema.
Estaba viendo un poco algunos temas, despues de la exposicion de Angel, y me surgio una duda.
 
En la imagen que adjunto, se nota que los Servicios no tiene conexion con el repositorio y tambien pude leer lo siguiente:
 
A good SERVICE has three characteristics.
 
     - The operation relates to a domain concept that is not a natural part of an 
       ENTITY or VALUE OBJECT.
     - The interface is defined in terms of other elements of the domain model.
     - The operation is stateless.
 
Statelessness here means that any client can use any instance of a particular SERVICE without regard to the instance's individual history. The execution of a SERVICE will use information that is accessible globally, and may even change that global information (that is, it may have side effects). But the SERVICE does not hold state of its own that affects its own behavior, as most domain objects do.
 
When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as a standalone interface declared as a SERVICE. Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LANGUAGE. Make the SERVICE stateless.
Sino entiendo mal los servicios deben ser sin estado, ahora si los uno a un repostorio es correcto?. Igualmente me imagino que esta persistencia de los servicio como la vi se refiere mas a guardar una configuracion, que a informacion que sera usada por el dominio.
 
Hay algo que me confunde un poco, este stateless se refiere al servicio, o a las operaciones del servicio?
 
Bueno como siempre si estoy escribiendo pavadas pido que me corrijan.
Saludos

Carlos Peix <[EMAIL PROTECTED]> escribió:
mmmmm, me parece que no, pero puedo actualizar el proyecto de ejemplo de la primera jornada para mostrarlo.
 
Carlos


From: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Leandro Tuttini
Sent: Jueves, 21 de Septiembre de 2006 02:35 p.m.
To: patrones List Member
Subject: !-> [patrones] Domain Model - Domain Service y el repositorio

Lista, que tal.
 
Carlos, una consulta en la ultima reunion espero haber entendido bien, comentaste que el Servicios del Dominio, como ser el caso de AdministracionVentas, etc, son objetos del dominio que de ser necesario puden tener su repositorio para persitirse.
 
Yo entendi que esta persistencia no tiene por que ser contra una base de datos, sino que puede tratarse de una archivos xml, o un .config.
 
Y es utilizado por el servicio para poder resolver la logica interna en runtime.
 
Carlos, por casualidad, tendrias algun ejemplo de como seria esto, como un servicio se persiste y utiliza la configuracion en tiempo de ejecucion.
Simplemente para ver como bajar esta idea a la implementacion.
 
Si ven que estoy diciendo cualquier cosa pido me corrijan.
 
Saludos

Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
Probalo ya!


Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
Probalo ya!

Responder a