tag:blogger.com,1999:blog-6168465570663215053.post690260657909232149..comments2023-04-13T02:14:26.637-07:00Comments on ALT+F13: Arquitecturas para Domain-Driven Design - Parte IVUnknownnoreply@blogger.comBlogger5125tag:blogger.com,1999:blog-6168465570663215053.post-10888098362212144042013-04-25T02:02:14.262-07:002013-04-25T02:02:14.262-07:00Para las vistas hay que utilizar Command Query Res...Para las vistas hay que utilizar Command Query Responsibility Segregation (CQRS) que consiste en utilizar "repositorios de vista" que permite traer la información de forma desnomalizada (1ª forma normal) para plantarla directamente en la vista.<br /><br />Podrías tener un repositorio que se trajese el modelo de vista siguiente:<br /><br />Class CheckPedidosViewModel{<br /><br />public int ClienteID;<br />public int PedidoID;<br />//mas propiedades<br /><br />}<br /><br /><br />RepositorioVistas.getCheckPedidosView() {<br />//codigo consulta<br /><br />return CheckPedidosViewModel<br /><br />}<br /><br />mostrar esto en un grid de una pagina web (esto es listar todos los pedidos) y cuando el usuario pulse el botón "Dar Visto Bueno" (una modificacion en el dominio) de una linea del grid; obtendremos el ClienteID y el PedidoID de esa linea, recuperamos el modelo de dominio a través de los "repositorios de dominio" y realizamos la acción:<br /><br />clienteSeleccionado = ClienteRepository.getByID(clienteID);<br />cliente.AceptarPedido(pedidoID)<br /><br />Para que esto surja de forma natural se requiere que la interfaz de usuario este basada en tareas (Task-Based UI) y no en CRUD; puesto que, aunque pueda parecer lo contrario, el diseño de la interfaz de usuario afecta directamente a la arquitectura de la aplicación.<br /><br />Con respecto a tu segunda pregunta.<br /><br />Un Producto no seria un aggregado de Pedidos puesto que realizar alguna modificación en el catalogo de productos o en algún dato del producto no implica tocar ninguna otra entidad para mantener consistencia y coherencia. Por lo que no necesita un contexto de transaccion para operaciones ACID. Por lo tanto, asumimos que Producto es una entidad con su correspondiente repositorio.<br /><br />Obviamente todo esto depende muchísimo del dominio de tu aplicación y no siempre en todos los sistemas un Producto tiene por que modelarse de esta forma.<br />J.L. Vaquerohttps://www.blogger.com/profile/11698680557880828975noreply@blogger.comtag:blogger.com,1999:blog-6168465570663215053.post-71501707953167488682013-04-25T02:02:06.076-07:002013-04-25T02:02:06.076-07:00Buenos días Martin.
El modelado de los agregados ...Buenos días Martin.<br /><br />El modelado de los agregados es el tema mas peliagudo de DDD.<br /><br />El diseño de agregados depende mucho de las necesidades, reglas e invariantes del dominio (ademas del rendimiento y escalabilidad, pero eso es otro tema). Un agregado tiene sentido cuando no puedes realizar alguna acción en una entidad sin que esto implique otra acción en otra entidad. Es un contexto de Transaccionalidad y ACID (http://es.wikipedia.org/wiki/ACID).<br /> <br />En el ejemplo que pongo puedes observar que modificar (darle el visto bueno o marcarlo como erróneo) un pedido conlleva chequear si el usuario tiene la cuenta bloqueada, por lo que debes tener en memoria el cliente y realizar la acción de dar el visto bueno al pedido a traves de la entidad Cliente. <br /><br />Realizar la tarea a través de la entidad raíz ( Cliente.AceptarPedido(idPedido) ) permite que el cliente pueda chequearse a si mismo para corroborar que puede aceptar el pedido o, por ejemplo, que tenga la cuenta corriente bloqueada y no deba aceptar mas pedidos. Es cuestión de diseñar bien las clases y encapsular las responsabilidades (en este caso es el cliente el responsable de negarse a aceptar un pedido). <br /><br />En un buen diseño orientado a objetos verás que se cumple la máxima "No preguntes, pide". No preguntamos por el estado del Cliente y realizamos una accion. Le debemos pedir al Cliente que realice la accion y el cliente decida si puede o no. No debemos tener en nuestro sistema código que se repite en un montón de sitios preguntando cosas como estas:<br /><br />If (cliente.ctaBloqueada and cliente.numPedidos < 3) or cliente.saldo > 0 {<br /><br /> pedido.aceptado = true<br /> cliente.numPedidos++<br /><br />}<br /><br />En el caso de Cliente.AceptarPedido(idPedido) la entidad Cliente internamente se encargara de aplicar sus invariantes llamando a sus propios métodos privados(Cliente.PuedoAceptarPedidos() que englobaría this.CtaCorrienteIsBloqued() and this.TengoPedidosAlMaximo(), etc; y así ir desgranando las responsabilidades poco a poco).<br /><br />Como puedes ver, las entidades de dominio y los agregados se utilizan para encapsular las reglas y las invariantes a las acciones. Esto solo tiene sentido cuando realizamos una tarea en el sistema que implica alguna modificación (insert, update, delete).<br />Para no podernos saltar esta encapsulación creamos "repositorios de dominio" que solo permiten obtener agregate roots o entidades que no son agregados raiz pero que no son "hijos" de ningun agregado (obviamente). Estos repositorios tiene funciones de consulta para traerse entidades de persistencia pero solo se usan para obtener las entidades a las que le vamos a realizar la tarea pertinente que nos haya mandado el usuario.<br /><br />J.L. Vaquerohttps://www.blogger.com/profile/11698680557880828975noreply@blogger.comtag:blogger.com,1999:blog-6168465570663215053.post-37097452521188213112013-04-24T07:06:40.617-07:002013-04-24T07:06:40.617-07:00Buen dia despues de haber leido tu articulo me sur...Buen dia despues de haber leido tu articulo me surge dos pequeñas dudas. <br />1.Solo los agreggate roots tienen repositorios no? Entonces en tu ejemplo solo exisitiria un repostiorio para Cliente. Pero y si quiero listar todos los pedidos?. Tengo que obtener todos los clientes y luego de ahi listar los pedidos para cada uno?<br /><br />2. Supongamos que tenemos tambien la entidad Producto, en este caso un producto seria un Agreggate Root o un Agreggate de Pedido?<br /><br /><br />Saludos! <br />Muchas Gracias!!!<br /><br />Anonymoushttps://www.blogger.com/profile/02227596042039525890noreply@blogger.comtag:blogger.com,1999:blog-6168465570663215053.post-43334354844626554892013-03-03T23:14:52.713-08:002013-03-03T23:14:52.713-08:00Muchas gracias. Pero en este caso el merito no es ...Muchas gracias. Pero en este caso el merito no es mio. Mi intención no es enseñar teoria DDD; si no llevar esa teoría a la practica en una arquitectura de software. Estos posts son muy introductorios y básicamente son una amalgama resumida de los artículos y libros con los que yo he aprendido DDD. Al final del repaso de teoría pondré un post con las referencias dando el merecido crédito a la gente que realmente ha escrito esto.J.L. Vaquerohttps://www.blogger.com/profile/11698680557880828975noreply@blogger.comtag:blogger.com,1999:blog-6168465570663215053.post-51635372647200910102013-03-02T08:09:34.476-08:002013-03-02T08:09:34.476-08:00Muy buen artículo! Y es que cada vez me confundía ...Muy buen artículo! Y es que cada vez me confundía sobre los Agregados.<br /><br />Saludos desde Santa Cruz, Bolivia.<br /><br />Twitter: @uialbertoAlberto Baigorriahttps://www.blogger.com/profile/12418333417588721326noreply@blogger.com