Open gyoandjoe opened 9 years ago
Resumen de Intro
Intro
¿Qué es el software? El software es un medio para un fin, que nos ayude a lidiar con las complejidades de nuestra vida moderna.
¿Cómo debe ser el software? Debe ser practico y útil, eso significa que debe estar extremadamente conectado a ciertos aspectos de nuestra vida, a cierto dominio, un software no puede estar desacoplado de cierta esfera de la realidad, de otra manera el software se vuelve muy problemático.
¿Cómo se diseña un software? Es un arte, no puede generarse por formulas establecidas, ciertamente hay principios y técnicas útiles aplicadas al proceso de creación de software, pero no hay un camino establecido que seguir, que comience con la necesidad del mundo real y termine en un producto de software.
¿Qué es DDD? Es un enfoque de diseño de software que ha emergido en las ultimas 3 décadas.
tengo algunas dudas, podrían ayudarme a entender mejor esto:
@gyoandjoe esto es lo que puedo entender como diferencia entre dominio y modelo de dominio.
El dominio es la descripción del problema mientras que el modelo es la abstracción de software que le da solución.
Creo que la parte más importante de este capítulo es que señala la importancia de adquirir el conocimiento del dominio para poder generar un modelo que le dé una solución de calidad. Y lo importante que es la comunicación con los expertos del dominio, porque sin ellos no podríamos reflejar en nuestro modelo las características que mejoren/solucionen los problemas de dominio.
Tratando de hacer una comparación simple el diseño de código, lo veo más relacionado con la implementación de tus clases/módulos/paquetes y el diseño de software describe cómo es la comunicación/interacción/organización entre ellos.
ah ya!, gracias @MontealegreLuis Dominio lo que el experto sabe. Modelo de dominio es lo que abstraemos del dominio.
Mi duda fue que cuando habla de una homogeneidad (en la sección del lenguaje ubicuo ) entre la comunicación, no entiendo como se llega a ese punto, entendí que las dos partes: el experto del dominio y los desarrolladores(arquitecto y programadores) llegan como a un acuerdo para ahora si entenderse, pero ¿como se llega a eso?
Los desarrolladores no pueden hablar al nivel del experto del dominio porque no conocen el dominio y el experto no (necesariamente) conoce de tecnologias,POO y asi..
Aunque en el libro dice que en la vida es más complicado que en el ejemplo del sistema de vuelos, si me causo algo de duda eso.
Ya leyendo esto me gusto esa parte de la comunicación, es raro para mi porque vengo de la escuela donde el programador es tímido y no se le da eso de la comunicación. :P
Rescato estas frases que a mi parecer fueron interesantes:
Is it possible to create complex banking software without good domain knowledge? No way. Never.
They know all the details, all the catches, all the posible issue, all the rules. This is where we should always start: domain.
The entire purpose of the software is to enhance a specific domain
How can we make the software fit harmoniously with the domain? ... make software a reflection of the domain A domain model is not a particular diagram; it is the idea that the diagram is intended to convey
We can and we should create a language to communicate specific issue about the domain.
Good coding techniques help to create clean, maintainable code.
A core principle of Domain-driven desing is to use a language based on the model
@Pazthor para mi una de las cosas más valiosas de DDD es el lenguaje ubicuo, porque te ahorra los costos de traducción entre expertos de dominio y programadores. Por ejemplo, supongamos que el experto de domino dice algo como queremos saber cuales fueron los productos vendidos en un rango de fechas, por que eso nos permite ahorrar blah, blah..
Uno llega al código y escribe:
$productRepository->findBy($date1, $date2);
Pero ese no es el lenguaje que el experto usa, nunca hablo de repositorios
ni de un método finder
. Si queremos respetar ese lenguaje ubicuo nuestro código debe ser más expresivo a fin de describir la intención de esa línea de código y no la implementación.
Que pasa si en lugar de eso escribimos:
$allProducts->soldDuring($aDateRange);
Y es por eso que se recalca la importancia de compartir el modelo, si el modelo se comparte al desarrollador, el desarrollador puede expresar ese mismo lenguaje en el código.
Veamos las definiciones del diccionario:
dominio. (Del lat. dominĭum).
¿Cuáles de esas acepciones ayudan a entender cómo aplicar el concepto de dominio al desarrollo de software?
Podemos ver también la definición:
modelo. (Del it. modello).
Gracias por sus respuestas, ya me quedo mas claro, pero tengo otra duda, como dice @MontealegreLuis el diseño de software es la composición y organización general de las partes del software, eso me hace pensar en el diseño de la arquitectura CQRS como ejemplo, pero el libro dice que hay varios enfoques de diseño de software y hace mención de los en cascada y métodos agiles, pero ¿que no esas eran metodologías de desarrollo?
@gyoandjoe creo que te refieres a esta parte
There are different approaches to software design. One is the waterfall design method.
Si son metodologías, creo que lo que quiere expresar en esos dos párrafos es que ambas te sirven como un medio para diseñar software no que sean el diseño en sí.
Si en efecto a esa parte me refería, creo que lo lei mal, debería leerse, "hay diferentes enfoques para hacer diseño de software, uno es cascada,,,", gracias
Y también respondiendo la pregunta de @pazthor , de como se llega al lenguaje ubicuo, según el ejemplo de la conversación entre el experto y el desarrollador para el problema de control de trafico aéreo, el lenguaje ubicuo se logra con mucha comunicación, acuerdos y concesiones entre los participantes del proyecto, por ejemplo hay podemos ver como el desarrollador logra acordar que una ruta será representada por una serie de puntos fijos 2D, de ahora en adelante todos en el equipo saben que es una serie de puntos, y pueden hablar de series de puntos sin problemas, y eso es parte del lenguaje ubicuo. Que como se representa el lenguaje ubicuo?, puede ser con diagramas, documentos, código, etc
Hola chicos los temas que vamos a tratar esta primera semana son los siguientes: Introduction What Is Domain-Driven Design The Ubiquitous Language Model-Driven Design (Only Intro)