Re: [altnet-hispano] Arquitectura DDD, es esto DDD?
nelopa...@gmail.com
según entiendo, DDD es una metodología de trabajo que propone una
arquitectura determinada, pero no dejes fuera la metodología (al menos
no inconscientemente).
te recomiendo que veas la VAN de Angel sobre DDD para entender del tema.
saludos.
nelo
2012/6/29 Martin Vecchione <martin.v...@gmail.com>:
> Hola buenas tardes a todos!!
> soy nuevo en el grupo asi que me presento!
>
> Estoy intentando migrar una aplicacion Mediana-Grande que tiene mas de 10
> años a una plataforma web (usando WebForm + Entity Framework 4.1) !
> estaba interesado en utlizar la arquitectura llamada Domain Driven
> Design!...Despues de buscar mucho en internet llegue a las siguientes
> conclusiones...
>
> Domain Driven Design.
>
> DOMAIN MODEL (POCOS y DTO)
>
> Entidades (Poco) y DTO (data transfer objects)
>
> · Validaciones básicas de la entidad.
>
> Se puede hacer usando Fluent validation. Ejemplo: El auto tiene que tener un
> motor.
>
> · Comportamiento de la Entidad.
>
> El auto es Azul!. ¿Que tipo de Auto es?
>
> REPOSITORIES
>
> Conoce al Domain Model
>
> · CRUD (create read update delete)
>
> DOMAIN SERVICES (corazón de la aplicación)
>
> Cuando un proceso no es responsabilidad de la entidad.
>
> Conoce al Domain Model y al Repositorio.
>
> · Reglas de negocio.
>
> Ejemplo: El auto no se puede vender si no tiene patente. Consulta entidad
> auto y patentamiento.
>
> · Son transacciones.
>
> Ejemplo: Vender el auto.
>
> · Puede utilizar varias entidades.
>
> (Auto, cliente, vendedor)
>
> · No mantiene un estado. Empieza y termina.
>
> APPLICATION SERVICE
>
> Responsable del Workflow de la aplicación.
>
> Conoce al Domain Model al Repositorio y al Domain Services.
>
> · No tiene reglas de negocio.
>
> · Coordina el uso de los Domain Services.
>
> · Puede utilizar al repositorio para devolver información.
>
> · Puede preguntarle a al entidad por cierto estado y realizar una
> validación simple. Ejemplo: Contrato Finalizado.
>
> · Coordina el manejo de excepciones.
>
> UI (User interface)
>
> Pantallas del cliente.
>
> Conoce a Poco (Solo usa DTO) y al Application Services
>
> · Llama al Application Service.
>
> · No deberia usar Pocos sino DTO!
>
> · No tiene logica de negocio.
>
> · Contiene lógica de presentacion.
>
>
> Estoy abierto a todo tipo de sugerencias, correciones, etc todo lo que me
> sirva para aprender!
>
> Desde ya muchas gracias y un saludo a todos
>
> Martin Vecchione
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de
> Grupos de Google.
> Para ver este debate en la Web, visita
> https://groups.google.com/d/msg/altnet-hispano/-/pYUiPV7ryikJ.
> Para publicar una entrada en este grupo, envía un correo electrónico a
> altnet-...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a
> altnet-hispan...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en
> http://groups.google.com/group/altnet-hispano?hl=es.
Mauro Decima
Convertí tus archivos a pdf gratis en http://www.guardarcomopdf.com
Angel Java Lopez
Carlos Peix
An primer lugar, creo que DDD no es exactamente una arquitectura. Hay arquitecturas mas amigables con DDD y otras menos.
En DDD el "corazon" de la aplicacion es el conjunto de los objetos que representan a los conceptos (el modelo). En DDD se consideran tres estereotipos de objetos dentro del modelo: entities, value objects, services.
En la ultima frase hay dos terminos que no deben confundirse terminologicamente:
- Entities: son objetos tienen identidad, es decir, que se los referencia por un identificador. Suelen tener logica de negocio, segun la su responsabilidad que mana del concepto que modelan. No confundir con las entidades de otros modelos, que solo transportan datos y logica minima.
- Services: se utilizan para modelar servicios del dominio. No confundir con otros servicios externos al modelo como servicios de aplicacion, de infraestructura, etc.
Ademas de tu pregunta central, te sugiero que tambien evalues trabajar en ASP.NET MVC (en lugar de WebForms), a mi me gusta mas.
----------------------------------
Carlos Peix
Kiquenet
Angel Java Lopez
Jorge Rowies
Si estás interesado en DDD, te recomiendo el libro de Evans
"Domain-Driven Design: Tackling Complexity in the Heart of Software"
(http://www.amazon.com/gp/product/0321125215/)
También hay un libro, cuya versión en pdf es gratis, que es un resumen
del de Evans, "Domain Driven Design Quickly"
(http://www.infoq.com/minibooks/domain-driven-design-quickly/).
Saludos
2012/6/29 Martin Vecchione <martin.v...@gmail.com>:
> Hey!!
>
> Muchisimas gracias a todos por sus respuestas como veran me falta mucho para
> terminar de entender los que es DDD y lo que no es!
>
> Ahora voy a leer todos los links que aportar a mi causa de entender el
> concepto de Domain Driven Desing!!
>
> De verdad muchas gracias ;)
Jorge Fioranelli
sergio
inge...@gmail.com
) de todas formas
al ver que hay un buen interes en este tema primero te quiero compartir un link
que encontre en las horas de investigación sobre el tema y que me parece
genial... por que lleva un paso a paso de como hacer un aplicación. Luego de
este puedes ya entrar a revisar un poco N-Layer que tiene todo un libro y una
app muy completa (tanto que a veces es complejo entender por donde va...) pero
igual creo que unai y cesar de la torre son algunos de los creadores de este
ejemplo saben bastante sobre el tema y pues las criticas destructivas estan de
mas.Jorge Fioranelli
Max Gmail
Para anular tu suscripción a este grupo, envía un correo electrónico a mailto:altnet-hispano%2Bunsu...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.
--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a mailto:altnet-hispano%2Bunsu...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.
Jorge Fioranelli
Jorge Fioranelli
Max Gmail
Max Gmail
Servicios del Dominio => NO conocen los repositorios, solo realizan operaciones entre Entidades.; esto con el fin de aplicar TestUnitarios a la capa del dominio sin depender de los repositorios.
El lunes, 16 de julio de 2012 15:27:52 UTC-5, Max Rodriguez escribió:
Hola,discúlpame creo que el error era mas de capa 8 jejeje por que daba click sobre el link y me enviaba a algo de outlook pero copiando y pegando sobre el browser si me funciona...Esta buenísima la herramienta y la forma de organizar una investigación creo que me copiare del método....Y pues con el tiempo les iré contando los resultados de la lectura para generar mas debate e ir construyendo mucho mas sobre DDD en este grupo la verdad me apasiona mucho este tema de la arquitectura de software y por ahora estaré centrado en DDD y TDD ya mirare cuando termine todo eso con que continuar si es que para cuando termine no este mando a recoger todo lo que leí...Gracias,From: Jorge FioranelliSent: Monday, July 16, 2012 3:13 PMSubject: Re: [altnet-hispano] Re: Arquitectura DDD, es esto DDD?
Va de nuevo (se me escapo el send):SaludosJorge--
On Tue, Jul 17, 2012 at 6:07 AM, Jorge Fioranelli <jorge.fi...@gmail.com> wrote:
Acá van de nuevo (corregidos):http://www.mindmeister.com/de/181195534/cqrs-ddd-links
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-hispano@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispano+unsubscribe@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Martin Vecchione
Juan Manuel Lombana Martinez
El martes, 17 de julio de 2012 09:04:50 UTC-5, Max Rodriguez escribió:
Hola,
Max Gmail
) haciendo dominios
anémicos con entidades q solo tienen propiedades que son campos en la base de
datos y 0 lógica y/o peor aun responsabilidad, los servicios de dominio son mas
excepciones a la regla de cuando tu regla de negocio no encaja en tu entidad que
tratar de poner todo en un servicio por que tiene algo como factura.detalle es
algo a evaluar, pero repito siempre termino haciéndolo como no es por el tema de
la costumbre de programar mal....Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Jhonnys Lopez Celedon
Martin Vecchione
El martes, 17 de julio de 2012 17:46:43 UTC-3, Max Rodriguez escribió:
Hola,
Ok intentare contestar desde mi punto de vista las dudas de este tema...1.- si es correcto los repositorios se implementan en una capa intermedia llamada infraestructura pero lo fundamental en DDD es el DOMINIO principalmente, esto significa que cuando tu defines la forma como vas a obtener la información de tu sistema de persistencia <BD, txt, MomgoDB, Mocks... etc> especificas un reportorio para esto, técnicamente en código es una interfaz en tu dominio el hecho que tu la implementes en infraestructura, ella esta definida en tu dominio... por esto digo que son en parte “servicios de dominio” por que su funcionalidad es bríndale a nuestro dominio un método para acceder a tu sistema de persistencia. Ahora quiero hacer una aclaración puntual Unidad de trabajo no es mas que un patrón para realizar reunir las transacciones necesarias y ejecutarlas en un solo momento y no tiene nada que ver con CRUD o Paginación esta lógica esta implementada en el repositorio no en la Unidad de Trabajo... tanto así que el repositorio usa a la UoW y no al revés por ende el UoW no esta haciendo nada de CRUD simplemente esta lanzando un cola de peticiones pendientes en un solo momento a tu BD o sistema de persistencia.2.- Primero que pasa si... es una pregunta que nunca podrás contestar por que sin un limite puedes hasta reinventar Windows y no terminar... pero esto es mas (Ingeniería de requerimientos) ahora comprendo tu pregunta y es un ejemplo diferente para ver que sucedería entonces yo lo solucionaría así. Primero mi factura es un agregado que contiene los detalles de la factura por ende mi factura es la única autorizada para hacer la suma de tus detalles, ahora bien puedes crear una clase que haga el metodo sumar detalles dentro de factura ó un servicio que llame a factura le pida la suma y el la de como resultado... en ultimas es una función exclusiva de la factura y es su responsabilidad como agregado realizar este calculo. En respuesta no seguiría siendo un método de tu factura ya que ella es la responsable del agregado... Ten cuidado por que siempre (yo termino) haciendo dominios anémicos con entidades q solo tienen propiedades que son campos en la base de datos y 0 lógica y/o peor aun responsabilidad, los servicios de dominio son mas excepciones a la regla de cuando tu regla de negocio no encaja en tu entidad que tratar de poner todo en un servicio por que tiene algo como factura.detalle es algo a evaluar, pero repito siempre termino haciéndolo como no es por el tema de la costumbre de programar mal....
3.- en esta creo que de cierta forma me das la razón al primer punto pero desglosemos por partes:3.1- Validación te recomiendo ver la forma como en N-Laver V2.0 realizar la validación de una entidad, me parece genial y muy limpia de hacerlo, sobre todo por que acumulas errores y se los muestras todos al usuario no estas enviando 1 por 1...3.2- Si necesitas crear una validación contra la base de datos yo lo resolvería creando efectivamente un servicio de dominio donde recibe la factura y el repositorio pertinente... y es acá donde digo que los repositorios son de dominio (para retirar el “es como un servicio” encargado exclusivamente de tratar con tu sistema de persistencia) lo trataremos por su nombre diferenciador “Repositorio” entonces si bien remitiéndome a lo que Juan Manuel escribe sobre la capa de aplicación si bien allí es donde hace algo como esto:Dominio.Repositorio.IRepositorioFactura facRepo = new Infraestructura.Repositorio.RepositorioFactura(new UnidadDeTrabajo());allí no es donde tu haces el facRepo.ObtenerFacturaParaValidar(123); o las consultas necesarias, estas creería las haces en dominio utilizando algo como Satisfy By o Policy o simplemente en código con un if haciendo visible tu regla de negocio por ende seria error grave (lo suelo cometer) migrar lógica de dominio a aplicación solo por que allí es donde instancias tu repositorio, ahora si tienes en cuenta lo que te digo en el punto 1 sobre repositorio, tu simplemente en tu dominio harias uso de tu repositorio para aplicar la regla de tu negocio y todo esto es posible por que quien define tu repositorio de Factura es tu dominio no tu capa de infraestructura o de aplicación.Espero haya sido claro en mi forma de entender DDD y como se ve plasmada en este caso puntual, no soy un gurú, recién he empezado a trabajarlo seriamente con DDD y como viste en muchos casos en la practica hago todo lo contrarío pero bueno es cuestión de tiempo corregir mis proyectos y mejorar.Ahora para cerrar y no aburrir retomo mi inicial propuesta como verán de útil esta discusión pero sobre una investigación formal y tratando de generar código como recomienda DDD... bueno para mi sería genial espero y algún momento les suene la idea.
From: Martin VecchioneSent: Tuesday, July 17, 2012 12:22 PM
Max Frank Gmail
Hola Martin,
Pues la verdad me alegra mucho que te haya quedado claro mi punto de vista, principalmente empecé al revés el estudio sobre DDD, como te comentaba en esta serie de correos y ahora creo que es mejor concentrase en el objetivo de DDD (Domino, Lenguaje Ubicuo) y luego vas mirando como implementas todo lo relacionado con patrones y buenas prácticas…
Como dijo Jorge en este correo… su blog de arquitectura esta bueno para eso, para que veas como los patrones se aplican y diferentes “reglas/practicas” que DDD explica y sobre todo como se realizan en .Net, pero para todo esto te recomendaría sinceramente primero leer y releer a Evans <Una vez leí un libro de Carnieg sobre consejos de tratar a la gente y el en entre todo esto dijo algo genial: que para entender un cap de un libro debes leerlo primero para ver de qué trata, que dice el autor, y luego al releer si te enfocas en aprender lo que él te está queriendo enseñar en dicho capitulo.>
Igual y a mí me falta bastante para terminar ese libro y ni para que hago cuentas con los links del mapa mental que envió Jorge… pero bueno creo que es más lo que tengo para aprender que para enseñar pero hay vamos…
Cordialmente,
Max Frank Rodriguez H.
Transfiriendo S.A.
Ingeniero Desarrollador de Software.
@ingmaxfrank
http://learnmax.wordpress.com/
No imprimas este correo.
Deja de usar Papel a menos que sea estrictamente necesario, este planeta te alimenta a diario y te provee oxigeno toda tu vida es justo que se le regrese el 1% de ese favor.
La investigación es mas valiosa que el conocimiento. –Alber Einstein-
De: altnet-...@googlegroups.com [mailto:altnet-...@googlegroups.com] En nombre de Martin Vecchione
Enviado el: Wednesday, July 18, 2012 9:41 AM
Para: altnet-...@googlegroups.com
Asunto: Re: [altnet-hispano] Re: Arquitectura DDD, es esto DDD?
Max,
De verdad que me ha servido tu explicación...
Entiendo a lo que te refieres con un dominio anemico, en un primer momento tuve una gran duda de agregarle a la entidad conocimiento de la persistencia para evitar un dominio anemico, pero terminaría cayendo en algo peor...
Por lo pronto me he bajado el codigo de ejemplo que nos a enviado Jhonnys López Celedon
Como tu dices DDD es una metodologia y como tal es cuestion de perderle el miedo, ponerla en practica y tratar de corregir los errores que indefectiblemente van a surgir!
Muchas gracias por tu ayuda!!
El martes, 17 de julio de 2012 17:46:43 UTC-3, Max Rodriguez escribió:
Hola,
Ok intentare contestar desde mi punto de vista las dudas de este tema...
1.- si es correcto los repositorios se implementan en una capa intermedia llamada infraestructura pero lo fundamental en DDD es el DOMINIO principalmente, esto significa que cuando tu defines la forma como vas a obtener la información de tu sistema de persistencia <BD, txt, MomgoDB, Mocks... etc> especificas un reportorio para esto, técnicamente en código es una interfaz en tu dominio el hecho que tu la implementes en infraestructura, ella esta definida en tu dominio... por esto digo que son en parte “servicios de dominio” por que su funcionalidad es bríndale a nuestro dominio un método para acceder a tu sistema de persistencia. Ahora quiero hacer una aclaración puntual Unidad de trabajo no es mas que un patrón para realizar reunir las transacciones necesarias y ejecutarlas en un solo momento y no tiene nada que ver con CRUD o Paginación esta lógica esta implementada en el repositorio no en la Unidad de Trabajo... tanto así que el repositorio usa a la UoW y no al revés por ende el UoW no esta haciendo nada de CRUD simplemente esta lanzando un cola de peticiones pendientes en un solo momento a tu BD o sistema de persistencia.
2.- Primero que pasa si... es una pregunta que nunca podrás contestar por que sin un limite puedes hasta reinventar Windows y no terminar... pero esto es mas (Ingeniería de requerimientos) ahora comprendo tu pregunta y es un ejemplo diferente para ver que sucedería entonces yo lo solucionaría así. Primero mi factura es un agregado que contiene los detalles de la factura por ende mi factura es la única autorizada para hacer la suma de tus detalles, ahora bien puedes crear una clase que haga el metodo sumar detalles dentro de factura ó un servicio que llame a factura le pida la suma y el la de como resultado... en ultimas es una función exclusiva de la factura y es su responsabilidad como agregado realizar este calculo. En respuesta no seguiría siendo un método de tu factura ya que ella es la responsable del agregado... Ten cuidado por que siempre (yo termino ) haciendo dominios anémicos con entidades q solo tienen propiedades que son campos en la base de datos y 0 lógica y/o peor aun responsabilidad, los servicios de dominio son mas excepciones a la regla de cuando tu regla de negocio no encaja en tu entidad que tratar de poner todo en un servicio por que tiene algo como factura.detalle es algo a evaluar, pero repito siempre termino haciéndolo como no es por el tema de la costumbre de programar mal....
3.- en esta creo que de cierta forma me das la razón al primer punto pero desglosemos por partes:
3.1- Validación te recomiendo ver la forma como en N-Laver V2.0 realizar la validación de una entidad, me parece genial y muy limpia de hacerlo, sobre todo por que acumulas errores y se los muestras todos al usuario no estas enviando 1 por 1...
3.2- Si necesitas crear una validación contra la base de datos yo lo resolvería creando efectivamente un servicio de dominio donde recibe la factura y el repositorio pertinente... y es acá donde digo que los repositorios son de dominio (para retirar el “es como un servicio” encargado exclusivamente de tratar con tu sistema de persistencia) lo trataremos por su nombre diferenciador “Repositorio” entonces si bien remitiéndome a lo que Juan Manuel escribe sobre la capa de aplicación si bien allí es donde hace algo como esto:
Dominio.Repositorio.IRepositorioFactura facRepo = new Infraestructura.Repositorio.RepositorioFactura(new UnidadDeTrabajo());
allí no es donde tu haces el facRepo.ObtenerFacturaParaValidar(123); o las consultas necesarias, estas creería las haces en dominio utilizando algo como Satisfy By o Policy o simplemente en código con un if haciendo visible tu regla de negocio por ende seria error grave (lo suelo cometer) migrar lógica de dominio a aplicación solo por que allí es donde instancias tu repositorio, ahora si tienes en cuenta lo que te digo en el punto 1 sobre repositorio, tu simplemente en tu dominio harias uso de tu repositorio para aplicar la regla de tu negocio y todo esto es posible por que quien define tu repositorio de Factura es tu dominio no tu capa de infraestructura o de aplicación.
Espero haya sido claro en mi forma de entender DDD y como se ve plasmada en este caso puntual, no soy un gurú, recién he empezado a trabajarlo seriamente con DDD y como viste en muchos casos en la practica hago todo lo contrarío pero bueno es cuestión de tiempo corregir mis proyectos y mejorar.
Ahora para cerrar y no aburrir retomo mi inicial propuesta como verán de útil esta discusión pero sobre una investigación formal y tratando de generar código como recomienda DDD... bueno para mi sería genial espero y algún momento les suene la idea.
From: Martin Vecchione
Sent: Tuesday, July 17, 2012 12:22 PM
Subject: Re: [altnet-hispano] Re: Arquitectura DDD, es esto DDD?
Hola! muchas gracias por tu respuesta, es verdad lo que dices, deberia volver a releer a Evans pero no es algo facil y tampoco de cambiar la forma de programar (como tu dices yo tmb estoy muy acostumbrado a programar contra la BD)...
Aprovechando el hilo de la conversacion (y teniendo en cuenta que no he leido de nuevo a Evans) hago un par de preguntas que espero no oscurezcan tus consejos/explicaciones...
1. Cuando dices que el repositorio son en parte servicios de dominio, ahi me entra la duda, los repositorios no son acceso a datos? como una capa intermedia entre mis servicios de dominio y la infraestructura??..
2. En tu ejemplo de retornar el total de la factura, que pasa si para obtener ese dato no se tengo que acceder a una tabla que me dice el total de la factura (supongamos que el total es la sumatoria de varios detalles). En ese caso si debería ser un servicio de dominio?
3. En el caso de las validaciones que requieren acceder a la BD para consultar un dato también entrarian dentro de un servicio de dominio?? o irían a la entidad (esto no me suena mucho ya que para hacer esto la entidad de alguna manera deberia conocer a la BD y para mi me suena a antipatron ?
Desde ya muchas gracias por tu tiempo!!
Saludos, y espero que mis consejos sean claros y beneficiosos.
El martes, 17 de julio de 2012 11:04:50 UTC-3, Max Rodriguez escribió:
Hola,
a la primera si efectivamente no son CRUD si bien contienen un CRUD por que ellos son los responsables de realizar las implementaciones de todo el acceso a datos el concepto es aun mas global y sobre todo cuando implementas UoW como tu bien lo dices.
A la segunda no estoy de acuerdo ya que primero los repositorios son en parte “servicios de dominio” son aquellos servicios que nos dan acceso a infraestructura para realizar operaciones con la BD, si bien lo que dices es cierto de las colecciones creo que es mas claro si dices << los repositorios hacen el trabajo contra la BD siempre utilizando nuestras entidades, esto quiere decir te regresan una Persona, Ciudad, Factura etc... pero nunca te regresan o insertan un DataRow con la información de una persona... para Repositorios vs CRUD creo esta es importante tener claro esto >> para mi hay esta la gran diferencia. Ahora el tema de los servicios de dominio y que solo controla las entidades en un principio lo maneje así pero ahora que eh leído a Evans creo que es mas conveniente decir que es cuando vas a hacer una operación que no encaja correctamente sobre una entidad. Me explico, Cuando tienes una factura y quieres sacar su total debes implementar una funcion returnTotal() dentro de Factura pero cuando quieres no se consolidar el impuesto de las facturas bajo cierto parámetro debes realizar un servicio de dominio que realice esta tarea sobre varias Facturas o de pronto y la consulta SOLO TE RETORNA 1 FACTURA entonces consolidas solo 1, pero esto no significa que tu factura deba consolidarse sola.
Ahora en cuanto a mi experiencia antes estaba muy orientado a programar sobre la BD, esto quiere decir que siempre hacia el modelo de BD y luego si la aplicación... leyendo a evans eh cambiado totalmente mi forma de pensar... ahora trato de organizar mi idea de aplicación (Diseño) en base a objetos.. al comienzo del libro evans muestra ciertos ejercicios donde el pinta un par de cuadros y rayas y evidencia como esto tratado como objetos traídos del experto del negocio a código tal cual brindan resultados geniales. De hay que te recomiende mejor ver la forma de diseñar, analizar y sobre todo céntrate mucho en el lenguaje ubicuo, el concepto del la relación con el experto del negocio y hay si creo encontraras los mayores beneficios que brinda DDD después ya aplicaras y te preocuparas por las reglas de repositorio, specify by, loggin, trace, poco, selft-tracking y demás. Yo inicie así tanto así que primero leí el N-Capas de microsoft que te recomendé antes que a Evans (Grave error) pero ahora que estoy leyendo a Evans eh entendido mucho mas lo que en N-Layer quieren hacer.
Saludos, y espero que mis consejos sean claros y beneficiosos.
Sent: Monday, July 16, 2012 10:26 PM
Subject: Re: [altnet-hispano] Re: Arquitectura DDD, es esto DDD?
Aun que no lei todo, veo sobre tu resumen lo siguiente:
Repositorio => NO es CRUD, es presentar el acceso a datos como una colección; quien finalmente persite los datos es la Unidad de Trabajo.
Servicios del Dominio => NO conocen los repositorios, solo realizan operaciones entre Entidades.; esto con el fin de aplicar TestUnitarios a la capa del dominio sin depender de los repositorios.
El lunes, 16 de julio de 2012 15:27:52 UTC-5, Max Rodriguez escribió:
Hola,
discúlpame creo que el error era mas de capa 8 jejeje por que daba click sobre el link y me enviaba a algo de outlook pero copiando y pegando sobre el browser si me funciona...
Esta buenísima la herramienta y la forma de organizar una investigación creo que me copiare del método....
Y pues con el tiempo les iré contando los resultados de la lectura para generar mas debate e ir construyendo mucho mas sobre DDD en este grupo la verdad me apasiona mucho este tema de la arquitectura de software y por ahora estaré centrado en DDD y TDD ya mirare cuando termine todo eso con que continuar si es que para cuando termine no este mando a recoger todo lo que leí...
Sent: Monday, July 16, 2012 3:13 PM
Subject: Re: [altnet-hispano] Re: Arquitectura DDD, es esto DDD?
Va de nuevo (se me escapo el send):
Saludos
Jorge
On Tue, Jul 17, 2012 at 6:07 AM, Jorge Fioranelli <jorge.fi...@gmail.com> wrote:
Acá van de nuevo (corregidos):
--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.
--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/7iwwhJVRXzAJ.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.
--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/HbsPAHPB4TYJ.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.
--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/altnet-hispano/-/Jpi9SELwCmwJ.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com