First week

[gyoandjoe]

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)

[gyoandjoe]

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.

[gyoandjoe]

tengo algunas dudas, podrían ayudarme a entender mejor esto:

1. ¿Cuál es la diferencia entre dominio y modelo de dominio?
2. ¿Cuál es la diferencia entre diseño de código y diseño de software?

[MontealegreLuis]

@gyoandjoe esto es lo que puedo entender como diferencia entre dominio y modelo de dominio.

• El dominio se refiere a la descripción de los problemas o procesos del mundo real que tu software quiere resolver o automatizar.
• El modelo de dominio es la parte del dominio que vas a representar en tu software para resolver un problema o automatizar un proceso. Ese modelo es una representación abstracta del dominio que puede tener varias formas como diagramas, casos de uso, etc.

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.

[pazthor]

ah ya!, gracias @MontealegreLuis Dominio lo que el experto sabe. Modelo de dominio es lo que abstraemos del dominio.

Duda

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.

fin duda

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

[pazthor]

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

[MontealegreLuis]

@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.

[sparra]

Veamos las definiciones del diccionario:

dominio. (Del lat. dominĭum).

1. m. Poder que alguien tiene de usar y disponer de lo suyo.
2. m. Poder o ascendiente que se ejerce sobre otra u otras personas.
3. m. Territorio sujeto a un Estado. U. m. en pl. Se usaba especialmente para designar los territorios del antiguo Imperio británico que gozaban de autonomía plena, como el Canadá o Nueva Zelanda.
4. m. Territorio donde se habla una lengua o dialecto. Dominio lingüístico leonés
5. m. Ámbito real o imaginario de una actividad. Dominio de las bellas artes
6. m. Orden determinado de ideas, materias o conocimientos. El dominio de la teología o de las matemáticas
7. m. Buen conocimiento de una ciencia, arte, idioma, etc. Tiene un gran dominio del inglés
8. m. Der. Derecho de propiedad.

¿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).

1. m. Arquetipo o punto de referencia para imitarlo o reproducirlo.
2. m. En las obras de ingenio y en las acciones morales, ejemplar que por su perfección se debe seguir e imitar.
3. m. Representación en pequeño de alguna cosa.
4. m. Esquema teórico, generalmente en forma matemática, de un sistema o de una realidad compleja, como la evolución económica de un país, que se elabora para facilitar su comprensión y el estudio de su comportamiento. ...
5. m. En empresas, u. en aposición para indicar que lo designado por el nombre anterior ha sido creado como ejemplar o se considera que puede serlo. Empresa modelo. Granjas modelo.

[gyoandjoe]

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?

[MontealegreLuis]

@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í.

[gyoandjoe]

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