TL;DR: es difícil, pero aunque no tengas un experto a mano, hay partes del proceso que siguen siendo útiles.
La mayoría de artículos sobre DDD que leo últimamente, y especialmente en blogs en español, se centran en los detalles de implementación, que no dejan de ser algo anecdótico. Parece que el objetivo de DDD es estructurar nuestro código en Entities, ValueObjects, Repositories, Factories, etc. Nos centramos en ver cómo ha de ser la estructura de proyectos de Visual Studio, y parece que cuantos más proyectos diferentes tenga, mejor. Como mucho, si somos Advanced Power Certified Architects ™, podemos hablar un poco de Bounded Contexts o incluso de Shared Kernels.
Sin embago, lo más importante de DDD, su esencia, sólo se menciona de pasada (si hay suerte). Si DDD es Domain Driven Design, es decir, Diseño Dirigido por el Dominio, parece claro que lo más importante de todo, lo que dirige nuestro desarrollo, es el dominio, que podríamos definir como el ámbito para el cual estamos desarrollando la aplicación.
¿Por qué necesitamos un experto en el dominio?
En general nosotros, el equipo de desarrollo, no conocemos mucho de este ámbito, sobre todo al principio. Necesitamos alguien que nos enseñe lo que es el dominio. Alguien que discuta con nosotros, que nos explique lo que sabe, los problemas a los que se enfrenta y la forma en que los resuelve.
Distintos modelos de un mismo dominio: la cartografía (XKCD.com)
Una parte fundamental de nuestra labor será crear un modelo que nos permita manipular fácilmente ese dominio en nuestra aplicación, pero no es sencillo elegir ese modelo. Habrá muchos modelos posibles y cada uno tendrá sus ventajas, pero tendremos que decidir cuál es el que mejor se ajusta a los problemas que tenemos que resolver.
La persona que nos tiene que ayudar a conseguirlo es el experto en el dominio. Es quien realmente conoce la realidad y es quien nos puede ayudar a validar los modelos que vamos creando. El experto en el dominio desempeña un rol fundamental en el desarrollo de la aplicación.
¿Se puede hacer algo sin él?
Por desgracia, hay ocasiones en que tenemos que afrontar un proyecto y no podemos contar con un experto en el dominio para guiarnos. ¿Debemos descartar entonces el uso de DDD? Lo más probable es que sí, pero hay partes del proceso que siguen siendo útiles. Además, si se trata de un proyecto de largo recorrido, como puede ser un producto estándar (en lugar de un desarrollo a medida para un cliente concreto), puede ser interesante que nosotros mismos nos acabemos convirtiendo en expertos en el dominio.
Es necesario tener en cuenta que convertirse en experto en cualquier cosa no es fácil y requiere una inversión de esfuerzo y tiempo considerable. No obstante, si estamos desarrollando un producto estándar realmente no nos queda más remedio que asumir ese rol.
Podremos contar con la ayuda de algunos usuarios y su siempre importante opinión, pero rápidamente nos daremos cuenta de que cada potencial usuario de la aplicación tiene su propia idea de como deben ser las cosas, por lo que al final será labor nuestra unificar sus ideas y buscar una solución que sea útil y cómoda al mayor número posible de usuarios. Para poder llegar a eso, es necesario un cierto conocimiento del dominio.
OJO: Cuando hablo de nosotros me refiero al equipo encargado del proyecto, incluyendo la gente de desarrollo, el product manager, el product owner, el analista que pasaba por allí, el arquitecto enamorado del UML, los consultores de 500€/hora y la señora de la limpieza. No pretendo decir que todo sea responsabilidad de los que desarrollamos.
Si en lugar de un producto estándar estamos en un proyecto de poco tiempo de duración, que no se espera que evolucione demasiado en el tiempo y cuya lógica de negocio no es completa, directamente no importa si hay experto en el dominio o no. No uses DDD, pero por muchas otras razones.
De todas formas, hay partes de DDD como proceso que son útiles y que se pueden aplicar incluso aunque tengamos que ponernos nosotros en el papel de expertos sin serlo realmente.
La idea de crear un lenguaje ubicuo que nos ayude a modelar la realidad y, lo que es más importante, a dialogar sobre ella de una forma precisa, es muy útil, aunque sólo sea para la comunicación interna del equipo. Además esto nos ayuda a ponernos en la piel del usuario, intentar entender cómo piensa, a qué problemas se enfrenta y cómo resolverlos. De esta forma podremos resolver lo que realmente preocupa al usuario y crearemos un modelo pensado para resolver esos problemas y no otros.
También resulta útil intentar crear un modelo de dominio rico, siguiendo los patrones típicos de DDD (Entities, Repositories, …), tratando de encapsular toda la lógica posible en las entidades, aislando las partes externas al sistema mediante interfaces e inversión de dependencia y creando capas anticorrupción para protegernos en los puntos de integración. Con ello conseguiremos también una aplicación más sencilla de testear con test unitarios.
¿Es necesario esto para hacer DDD? Lee los comentarios...
En el fondo, muchas de esas cosas no son más que buenas prácticas genéricas de todo desarrollo de software y, en concreto, de programación orientada a objetos.
Lo que no tiene sentido es lanzarse ciegamente una y otra vez a seguir ejemplos de arquitecturas complejas que no tienen nada que ver realmente con DDD.
DDD es un proceso, no una arquitectura.
Actualización (24/11/2011): No os perdáis en los comentarios las explicaciones de Unai y César sobre el ejemplo de Domain Oriented N-Layer App de Microsoft.
Juanma, totalmente de acuerdo con tu apreciación con respecto al experto del dominio y demás consideraciones acerca de su importancia con respecto a DDD.
No obstante, no estoy de acuerdo es tu señalamiento a Microsoft NLayer. Permíteme señalarte nuestro scope «.NET 4.0 wave technologies implementing typical DDD patterns»….
Efectivamente, un ejemplo de arquitectura no es DDD, pero no es menos cierto que hay un GAP despues de saber que es DDD para implementarlo, y ahí entra este ejemplo. Por lo tanto, tu apreciación es injusta porque intentas argumentar que eso se vende como DDD cuando en realidad no es asi…
Un saludo
Unai
Gracias por el comentario, Unai.
El mayor problema que le veo a NLayer es que la gente no lee lo que habéis escrito (donde dejáis muy claro el ámbito del ejemplo), sino que se va directamente al código.
Al ver el código, me parece que la arquitectura que tenéis es más N-Layer que DDD. Sinceramente, me recuerda más a las Petshops de cuando salió .NET que a otros ejemplos de arquitectura DDD, que suelen ser más onion o hexagonal.
De todas formas, reconozco el merito de introducir esos conceptos en la comunidad de desarrollo de .net. No es nada fácil y creo que en ese sentido vuestra labor es muy de agradecer.
Un saludo,
Juanma.
Juanma, te agradezco la puntualización. De todas formas en NLayer está muchos de los patrones de DDD, por lo tanto yo no la veo Petshops etc. Otra cosa, lógicamente es el proceso, definir el modelo, tu bc, el lenguaje ubicuo, el experto del dominio etc…. pero repito lo de mi primer comentario, sirve, para lo que es, para cubrir el gap de implementación con tecnología microsoft
Unai
Es cierto que aparecen varios patrones: tenéis repositorios, entidades, value objects, especificaciones, y eso lo veo genial (aunque discrepe con parte de la implementación). Entiendo que esa parte ayuda a cubrir el gap el del que hablas.
Por otra parte, el diagrama de capas que hay en la página principal me parece demasiado «enterprisey», muy complejo y con tecnologías metidas un poco «con calzador» (¿WWF? ¿WIF? ¿de verdad?).
Al final hay gente con la que he hablado de vuestro ejemplo que en lugar de quedarse con la parte buena (la implementación de patrones), se queda con la parte compleja y empiezan a montar capas y capas de abstracciones que no aportan nada, sólo porque está en un ejemplo «de Microsoft».
Sé que eso no lo podéis evitar y por eso quería aportar mi opinión al respecto, para dejar claro que esto no va de montar arquitecturas.
Juanma, toda la razón.. efectivamente no lo podemos evitar, nosotros aportamos algo a la comunidad con un propósito claro ( e hicimos enfasis en el todo lo que hemos podido ) a partir de ahí, las interpretaciones y demás no podemos vigilarlas ni castrarlas porque no llegamos a todo. Como dices esto no va de montar arquitecturas y te agradezco las apreciaciones. Acuérdate de que para un martillo todo son clavos, con esto, y con otras tantas cosas de comunidad, tecnologías, frameworks etc…
Te escribiré un correo para discutir que cosas «no te terminan de convencer» de la implementación, los comentarios no me parece la via más simple…
Unai
Hola Juan María,
Soy César de la Torre, de Microsoft, responsable del proyecto ‘Domain Oriented NLayered Architecture’. Quería hacer este comentario por tu referencia directa a nuestro trabajo.
Primeramente, decir, que estoy totalmente de acuerdo, DDD es mucho mas que patrones y Arquitectura, es una forma de afrontar el proyecto y la parte fundamental es el Modelado del Dominio. Pero eso lo hemos dicho innumerables veces en nuestra guía y también en la Home-Page de Codeplex done decimos «DDD is much more than this!» y explicamos por qué. Si se quiere saber qué es DDD, para eso tenemos desde hace años el libro de Eric Evans y otra literatura.
Sin embargo, cuando comenzamos este proyecto, precisamente lo que no había practicamente eran ejemplos y guía de implementación de patrones DDD, y eso UNICAMENTE es lo que quisimos hacer, llenar ese hueco de implementación de patrones.
Una anecdota que quiero contar, relacionado con la frase que dices de que nuestro proyecto no tiene NADA que ver con DDD…
Hace 2 semanas, a traves de IASA-Spain, hicimos una conferencia DDD y unos Workshops, con el propio ERIC EVANS y con UDI DAHAN. Después de un Workshop, hablando con Eric Evans de nuestra Guía de Arquitectura y patrones que haces referencia, le dijimos precisamente que le habíamos llamado «Domain Oriented» porque no cubrimos todo DDD, solo la parte de patrones e implementación en .NET, y me dijo: «Da igual, son patrones DDD y podríais e incluso deberíais haberle llamado Patrones DDD. No pasa nada!, es una parte complementaria con todo lo que yo explico.».
En definitiva, creo que deberíamos aclarar las cosas y ayudar de forma constructiva todo lo relacionado con DDD, mas que tachar de incorrecto el trabajo de los demas sin resaltar las cosas positivas, no crees? :-)
En cualquier caso, recalcar que estamos completamente de acuerdo, DDD no es mucho mas que implementación de patrones, pero al final, la gente que lee el libro de Eric Evans , llega un momento que dice, ok, pero ¿Como implemento este patrón en .NET?, y eso fué simplemente lo que que´ríamos hacer… :-)
Gracias!
César.
Hola César,
Yo creo que si has visto los comentarios que he intercambiado con Unai te habrás dado cuenta de que en realidad estamos de acuerdo en casi todo :-)
De todas formas, de lo que hablo en el post es de:
Y eso lo mantengo. De hecho lo que pongo en mi post es una imagen de eso, de la arquitectura. Como proyecto, repito lo que le he dicho a Unai, creo que cubre aspectos de DDD de una manera que puede resultar útil.
En otro orden de cosas, enhorabuena por la conferencia del IASA, os quedó estupendamente.
Bueno, la Arquitectura que proponemos como punto de partida es simplemente la implementación de Capas propuestas por ERIC EVANS en una NLayered Architecture.
– Presentation Layer
– Application Layer
– Domain Layer
– Infrastructure Layer & Data Persistence Layer
No hemos inventado algo nuevo-complejo, es la Arquitectura de Capas propuesta por ERIC EVANS en su libro DDD, pero traducido a tecnologías .NET, no hemos ‘reinventado la rueda’ desde un punto de vista de Arquitectura. :-)
Cesar.
César, es verdad que Evans habla de todas esas capas, pero tal y como yo lo entiendo, no obliga a que cada capa hable sólo con la capa inmediatamente inferior, sino con cualquiera de las capas que tiene por debajo.
Para mi esa es una diferencia importante entre una arquitectura DDD y la clásica arquitectura de N-capas. En el diagrama que aparece al principio del capítulo «Layered architecture» (http://ajlopez.wordpress.com/2008/09/12/layered-architecture-in-domain-driven-design/) se ve claramente que UI puede saltarse Application Layer para acceder a Domain, o Application saltarse Domain para acceder a Infrastructure.
A mi es una de las cosas que me gustó de esa arquitectura, porque evitaba tener clases que no aportaban nada y sólo estaban ahí por rellenar el hueco entre capas y pasar la llamada de una capa a otra. Esto era algo muy frecuente en aplicaciones de 3 capas (como el ejemplo del Petshop), en las que para no acceder desde la capa de UI a la capa de DAL se pasaba por un BLL que muchas veces lo único que hacía era redirigir llamadas.
Creo que la diferencia fundamental, es que en una arquitectura N-Layer-Clasica, la capa de dominio depende de la capa de infraestructura, mientras que en una arquitectura NLayer-DDD el dominio no depende de ninguna capa, lo que nos permite aislarnos de la infraestructura y centrarnos en el desarrollo del dominio de una forma mas agil y sin «contaminaciones».
La guía no trata de explicar DDD, para esto está el libro de Eric Evans, sin embargo si trata de ilustrar cómo conseguir el aislamiento del domininio mediante el uso de tecnicas de IoC y el uso de un ORM cómo Entity Framework 4.1.
Sin embargo, si que creo que es importante que se haga más enfásis en que no es un libro de DDD para evitar malentendido. Por otro lado pienso que sería mas efectivo ilustrar los conceptos del Libro con un ejemplo de dominio mas complejo ( por ejemplo algo como http://dddsamplenet.codeplex.com/
pero usando EF en lugar de NHibernate )
Creo que no has visto bien nuestra Arquitectura. No es una NLayered tradicional.
– 1. Una NLayered tradicional tiene dependencias desde la capas superiores a las inferiores. Nuestra Arquitectura NLayered-DDD las dependencias van al final hacia la Domain Model Layer, porque es ahí donde están las Domain Entities e incluso los Contratos/Interfaces de los Repositories, aunque la propia implementación de los Repositories (clases) estén en Infrastructure. Todo eso son importantes Direfencias propuestas en DDD.
No son simplemente dependencias ‘hacia las capas inferiores’. Todo esto lo explico en el libro, comparando el approach tradicional con el DDD.
– 2. En nuestra arquitectura puedes llamar a otras capas, no solamente a la inferior, por ejemplo, puedes llamar desde la capa de Application (Application Services) a la capa de Data-Persistence (Repositories) sin pasar por la Capa de Domain Model Layer. Este simple ejemplo ya no cumple lo que dices de que ‘siempre se obliga a que cada capa hable solo con la inmediatamente inferior’.
– 3.- Cuando Eric Evans habla de Infrastructure Layer, habla de cualquier tecnología/librería/framework, no solo de acceso a datos. Y en el caso de UI, el que acceda a Infrastructure también puede ser porque esté, por ejemplo, haciendo uso de una librería gráfica, etc. Toda la orquestación a nivel de aplicación Eric deja muy claro que debe de hacerse en la Capa de Application, y no acoplar la Capa de Presentación con lógica de orquestación de aplicación, como dices.
Aunque para casos simples de consulta, también podría llegar a hacerse, llamar a Repositories por ejemplo desde una página ASP.NET MVC. Tampoco somos ‘talibanes’ en ese respecto. Lo importante es ser consistente en todo el desarrollo, no cada vez de una forma.
Lo importante de nuestra Guía y ejemplo es la propuesta de implementación de patrones DDD en .NET, que es solamente lo que queríamos hacer (no re-definir DDD) y lo que hemos hecho (propuesta de implementación de patrones DDD en .NET) es perfectamente complementario con DDD ‘como un todo’. Esto es lo que me confirmó el otro día personalmente Eric Evans. Incluso me dijo que podríamos haberlo llamado «DDD Patterns» y no hace falta descafeinarlo diciendo «Domain Oriented», aunque no cubramos muchos otros aspectos de DDD ‘como un todo’. Sigue siendo una parte complementaria en DDD, implementación én .NET.
Jústamente lo que quería explicar es que no es una arquitectura nlayered tradicional y sí una nlayer-DDD, ya que ilustra cómo aislar el dominio del resto de capas mediante IoC y EF.
El ejemplo que propones me parece más DDD, pero quizá se haga un poco duro para el que parte de cero. En ese sentido entiendo el compromiso que intenta alcanzar el ejemplo de Microsoft, aunque acabe con un dominio más anémico.
Sobre lo de hacer más énfasis en que no es un libro de DDD, es un poco lo que pretendía decir con las (escasas) referencias a esos proyectos en mi post. Una cosa es la arquitectura y otra es DDD.
Estoy completamente de acuerdo en que el uso de IoC ayuda a implementar DDD y en que no es una arquitectura nlayered tradicional.
De todas formas, el tema de cambiar la dirección de la dependencia no es de Evans, es de Uncle Bob y es muy anterior a DDD (es de un artículo de Mayo del 96). De hecho se puede hacer arquiectura N-capas tradicional con inversión de dependencia y eso no lo convierte en DDD (y te lo digo porque, aunque ahora me avergüenze, lo he hecho :-).
Otros puntos que me parece importante recalcar:
1.- Dices: «De todas formas, de lo que hablo en el post es de: ‘Arquitecturas complejas que no tienen nada que ver realmente con DDD
‘ y eso lo mantengo».
Bueno, no estoy de acuerdo, no puedes decir que una arquitectura compleja no tiene nada que ver con DDD, porque la Arquitectura y el Diseño forma también parte de DDD. Si no, Eric Evans no hablaría nada de NLayered, Patrones, Capas, etc.
Adicionalmente, la complejidad es algo inherente en los proyectos y arquitecturas DDD, porque un objetivo fundamental es aislar y proteger el código de la Domain Model Layer del resto de código de infraestructura y tecnologías, eso añade complejidad (por abstracciones necesarias para desacoplar elementos, etc.), así como la complejidad propia del Dominio.
Curiosamente, el libro de Eric Evans se llama «Tackling Complexity in the Heart of Software». –> ‘Complexity’ y se habla también mucho de Arquitectura…, curioso que digas ‘Arquitecturas complejas que no tienen nada que ver realmente con DDD’…
Una cosa es que dijeras ‘DDD es mucho mas que Arquitectura’ (100% de acuerdo), y otra que ‘la Arquitectura no tenga nada que ver con DDD’.
2.-Tanto en nuestro libro ‘Domain Oriented N-Layered Architecture’ como en la página home de CODEPLEX decimos que DDD no es solo Arquitectura y diseño, pero que nosotros nos hemos centrado solo en eso, porque el resto ya está bien definido por los promotores originales de DDD (Eric Evans y otros). ¿Qué parte de lo que decimos no lo ves así?, mira lo que decimos:
http://microsoftnlayerapp.codeplex.com/
«DDD IS MUCH MORE THAN THIS!
…, and this is extremely important, DDD is on the other hand, much more than just a proposed Architecture and patterns. DDD is a way to build apps, a way for the team, to work in projects. According to DDD, the project’s team should work in a specific way, should have direct communication with the Domain Experts (the customer, in many cases). The team should use an ‘Ubiquitous Language’ which has to be the same language/terms used by the domain experts, etc. But, all those ways to work are not part of this Sample-App, because it is process, kind of ALM, so, if you want to really “Do DDD”, you’ll need to read Eric-Evans’ book or any other DDD book where they talk about the DDD process, about the project and the team, not just the Architecture and patterns. Architecture and patterns are just a small part of DDD, but, in this case those are the points we are showing here (DDD architecture and patterns). But we want to highlight that DDD is much more than Architecture and design patterns.»
y..
«Reminding what DDD is and what this project is NOT covering!
Domain Driven Design is much more than Architecture and Design Patterns. It implies a specific way of working for development teams and their relationship with Domain experts, a good identification of Domain Model elements (Aggregates/Entity Model, etc.) based on the Ubiquitous Language for every Model we can have, identification of Bounded-Contexts related to models, and a long etcetera related to the application life cycle that we are not covering (only very slightly in our Guidance). There were already excellent literature and knowledge about that before this project was started, coming from people like Eric Evans, Martin Fowler, Udi Dahan, Greg Young, etc.
Our guidance and sample application focuses only on about a 20% of DDD subjects, we do NOT intend to teach DDD as a whole», we are only filling a gap we saw regarding implementing most useful Domain Oriented design patterns with the latest version of .NET.»
NUNCA hemos dicho que DDD sea solo Arquitectura, hemos dicho explícitamente todo lo contrario.
Lo que dices, «DDD es un proceso, no una arquitectura», es en parte una frase que es una falacia, porque la Arquitectura también forma parte de DDD, pero si sería correcto decir que ‘DDD es mucho mas’.
La frase debería ser «DDD es un Proceso, es mucho mas que una Arquitectura», y eso es precisamente lo que hemos repetido en muchas ocasiones.
Pero decir esa frase, y tachar nuestro diagrama como si no fuera parte de DDD o no tuviera nada que ver con DDD, es en lo que no estoy de acuerdo. Es un trabajo complementario a la teoróa de DDD. Cada uno de nuestros capítulos están basados en las definiciones teoricas de Eric Evans, con muchas referencias a sus definiciones lógicas y luego proponiendo implementaciones en .NET. Pero decir que no tiene nada que ver con DDD, se cae por su propio peso. El propio Eric Evans comentaba el otro día que ‘la implementación de patrones DDD, también forma parte de DDD’, es una parte.
Quiero también agradecerte tu feedback, pero creo que es diferente un feedback para mejorar algo, constructivo, bien en tu blog o bien en el site público de CODEPLEX Open Source, a hacer referencia a ello tachando nuestro diagrama de Arquitectura, diciendo que no tiene nada que ver con DDD e incluso dando a entender que es un mal trabajo.
Lo siento, pero no estoy de acuerdo, nuestro trabajo es complementario en una parte de DDD (implementación de patrones en .NET), lo cual era un gran vacío en el momento que nosotros hicimos ese trabajo.
Nunca hemos pretendido definir DDD en su globalidad, para eso está la excelente literatura de Eric Evans y otros autores, anterior a nuestro trabajo y a la que referenciamos constantemente. Ellos definieron la parte importante de DDD, el trabajo que hemos hecho es solo de patrones y arquitectura. No es lo mas importante en DDD, cierto, pero algo que al final hay que hacer e implementar y había un vacío en eso (implementación de patrones DDD en .NET) en la comunidad.
Por el hecho de que no abarcamos todo DDD, por eso decidimos titular al libro «Domain Oriented NLayered Architecture», sin el acrónimo DDD. Pero como comentaba antes, el propio Eric Evans me comentó que debiamos haberlo titulado con el acrónimo DDD, porque aunque no abarque todo DDD, la implementación de patrones SI forma parte de DDD. Que podría llamarse «DDD Architecture and .NET Patterns implementation».
Por supuesto que los patrones de Dependency Injection(DI) no son exclusivos de DDD; pero digamos que para facilitar el DDD es importante que el código de dominio evolucione de forma independiente al resto de código de infraestructura ( vease: código afin a una tecnologia ) y para esto ayudan mucho estos patrones.
César, creo que lo vemos de manera diferente (cosa que me parece bien y considero algo positivo) y estamos discutiendo en círculos.
De todas formas, si lees los primeros comentarios entre Unai y yo, me parece que la postura es mucho más cercana de lo que pueden aparentar estos últimos comentarios.
En cualquier caso, he actualizado el post para redirigir a estos comentarios y que todo el mundo pueda leer vuestra opinión porque me parece importante que así sea.
Por otra parte, sobre hacer una crítica constructiva «bien en tu blog o bien en el site público de CODEPLEX Open Source», no hubiera tenido ningún problema, pero fue Unai el que me pidió tratarlo por email, me pareció buena idea, y así lo hice. Creo que estás copiado en todos esos correos, si quieres ampliar algo sobre eso estaré encantado de hablarlo.
Siento que lo veas como un ataque directo al proyecto «Microsoft Spain – Domain Oriented N-Layered .NET 4.0 Sample App» porque no es esa mi intención. De hecho también enlazo otro artículo al principo del post.
Lo que trato de hacer es explicar que DDD es «MUCH MORE THAN THIS», por usar vuestras palabras. Mi intención era hablar de DDD fuera del contexto de la arquitectura y la implementación, recalcar la importancia de DDD fuera del plano «puramente técnológico» y contestar a una pregunta que me he hecho muchas veces, ¿se puede hacer ddd sin un experto de dominio?
En el fondo yo creo que casi todos estamos de acuerdo, aunque el matiz de tachar la foto puede que sea lo que le «mosquea» a Cesar porque puede parecer lo que no es, algo que aclaras también en los comentarios, pero a simple vista no me parece…
Sobre el feedback, efectivamente el correo me pareció buena idea, es más agil, de hecho, cuando suba algún cambio seguramente hare alguna reflexión sobr el mismo…
Unai
Con lo fácil que hubiera sido empezar por ahí… :-)
A ver qué tal ahora.
Estoy de acuerdo, Juanma, completamente con la frase «¿se puede hacer ddd sin un experto de dominio?», y que hace falta un experto del Dominio para hacer DDD, es mas, añadiría que hace falta siempre un modelo complejo y real así como por lo tanto, un proyecto real. Por eso, nuestra Guía de Arquitectura no cubre todo DDD, es solo una parte complementaria y por eso siempre hemos dicho que DDD es mucho mas, hace falta un proyecto real y un experto en el dominio. Nuestra iniciativa es solo para una parte que al final también tienes que hacer, la implementación de patrones.
Y si, tiene razón Unai, me mosqueaba la imagen tachada, alguien que lo leyera por encima podría entender que ‘se está tachando negativamente’. Por otro lado, también decir que es bueno recalcar que DDD es mucho mas que Arquitectura y patrones, nosotros lo hacemos siempre, también por eso quise traer a Eric Evans a la confenrencia DDD, para que se viera DDD en toda su extensión.
Este post, me parece bueno y acertado en su conjunto, simplemente no estaba de acuerdo con matices de ‘no tiene nada que ver’versus ‘es mucho mas que solo arquitectura y patrones’. Pero vamos, creo que en un 95% estamos de acuerdo. :)
Estoy empezando con DDD y estoy de acuerdo con los 2 puntos de vista aquí propuestos, por un lado el autor del blog esta en lo cierto que la arquiectura de Microsoft es demasiado compleja para un proyecto medio, pero no tiene razón cuando comenta que es una arquitectura N-Layered ya que el dominio no depende de niguna otra capa y estaría en el corazon de una arquitectura tipo onion. De todas formas este proyecto de microsoft como ellos mismos han dicho es una guía didáctica para introducir a la gente del mundo .NET en los patrones DDD, quiero dar mi agradecimiento pq he estado estudiando el código y a partir de él he extraido una arquitectura totalmente válida para mi proyecto.
hal,
Gracias por dejar tu opinión y me alegro de que te haya sido de utilidad la arquitectura de Microsoft.
En cuanto a que sea una arquitectura N-Layered, no es algo que diga yo. Es el nombre del proyecto, del libro y además lo defiende César en los comentarios más arriba.
Desde mi punto de vista, determinar si una arquitectura es N-Layered es una cuestión de si tiene capas o no, no de la manera en que dependen unas capas de otras. En el caso de la arquitectura de ejemplo, esas capas existen y además de forma muy rígida (para bien o para mal, según lo quieras ver).
Hola a todos, respecto al comentario del post he leído toda la conversación y me hago una pregunta, los expertos del dominio acuden a los proveedores de software para que le diseñen una solución de negocio, que le permita resolver los problemas que tienen en su negocio(empresa). En que caso se puede hacer una solución de negocio sin el experto del dominio? esta es mi pregunta.
Ahora desde mi punto de vista una solución de negocio se concibe desde el diseño de la solución de negocio. En mi caso Diagrama(casos de uso, actividad y clases). En el diagrama de clases ya se obtiene las reglas de negocio y el modelo conceptual para poder desarrollar la base de datos. El mundo real se lleva al modelo conceptual y se diseña la solución.
Una ves que se tiene hecho eso recién se puede ver que tecnologías usar. Si es una arquitectura 3 capas clásico o un n-capas DDD. En mi experiencia personal e usado DDD de los amigos de Microsoft iberica y solo he usado lo que necesitaba lo utilice para un sistema de un bar y me fue muy bien y estoy agradecido con ellos por su trabajo. Las tecnologías se usan deacuerdo a la envergadura del proyecto. Ojo que para el sistema del bar solo necesitaba un tres capas clásico, pero si se usa el DDD se puede usar lo que se necesite y listo.
El concepto básico de capas es ordenar el código, teniendo bien claro la responsabilidad de cada capa. Presentación, ingreso de datos y devolver información, mensajes, Lógica, llamado a métodos, AccesoDatos, persistencia contra la base de datos, Entidades, mapeo a las tablas.
Estoy, empezando en esto del dominio, pero creo que sali mas confundido que antes. Ruego porfavor ayudarme a iniciar en este tipo de arquitecturas con algunas bibliografias desde cero. Gracias de antemano
Hola Limber,
La bibliografía básica de este tema es «Domain-Driven Design: Tackling Complexity in the Heart of Software» de Eric Evans. Es el libro que lo empezó todo.
Tienes un libro con un enfoque más práctico (aunque las prácticas que aplica pueden ser discutibles) que es «Applying Domain-Driven Design and Patterns: With Examples in C# and .NET: Using .Net» de Jimmy Nilsson.
Ambos me los he leído y me parecieron útiles. Hay otro libro que no me he leído (todavía) pero que tiene buena pinta: «Implementing Domain-Driven Design» de Vaughn Vernon.
Un saludo,
Juanma.
Hola qué otros blogs lees sobre DDD?
Hola,
La verdad es que hace tiempo que no leo sobre el tema (supongo que pasó el hype, la gente se puso a escribir de CQRS, luego de contenedores, después de liberías de javascript y ahora de lenguajes funcionales), pero en el blog de Jimmy Bogard (https://lostechies.com/jimmybogard/author/jimmybogard/) había bastante material interesante.
Un saludo,
Juanma
Juanma, el tiempo te dió la razón :)
Lamentable el libro negro DDD de microsoft.