Patrones: Diseño orientado al dominio

Creo que si bien los conceptos son bien explicados en general para todos los patrones faltan ejemplos de la vida real que permitan tener mas claridad.

Apuntes:

Diseño orientado al dominio

Lo que hacemos es guiar nuestra aplicación y el diseño a través del uso del lenguaje común entre el negocio y el desarrollo. El obtener ese lenguaje del negocio y el poder hacer aplicaciones que estén concentradas en eso mucho más que lo que están concentradas en detalles técnicos. Va más allá de una sola aplicación, nos dice que busquemos modularizar nuestro sistema a través de los bounded context, que tratan de encontrar dónde el lenguaje cambia de sentido.

• Domain Driven Design (DDD) es un nuevo enfoque de desarrollo de software.

• Representa distintas claves, terminologíay patrones utilizados para desarrollar software donde** el dominio es lo más central e importante de una determinada organización**.

• Sus principios se basan en:

• Colocar los modelos y** reglas de negocio de la organización, en el core de la aplicación**

• Basar nuestro dominio complejo, en un modelo de software.

• Se utiliza para tener una mejor perspectiva a nivel de colaboración entre expertos del dominio y los desarrolladores, para concebir un software con los objetivos bien claros.

**Beneficios:
**

• Comunicación efectiva entre expertos del dominio y expertos técnicos a través de Ubiquitous Languge.

• Foco en el desarrollo de un área dividida del dominio (subdominio) a través de Bounded Context’s.

• El software es más cercano al dominio, y por lo tanto es más cercano al cliente.

• Código bien organizado, permitiendo el testing de las distintas partes del dominio de manera aisladas.

• Lógica de negocio reside en un solo lugar, y dividida por contextos.
  Mantenibilidad a largo plazo.

**Inconvenientes **:

• Aislar la lógica de negocio con un experto de dominio y el equipo de desarrollo suele llevar mucho esfuerzo a nivel tiempo.

• Necesitamos un experto de dominio

• Una curva de aprendizaje alta, con patrones, procedimientos,…

• Este enfoque solo es sugerido para aplicaciones donde el dominio sea complejo, no es recomendado para simples CRUD’s.

Está información la saqué de https://medium.com/@jonathanloscalzo/domain-driven-design-principios-beneficios-y-elementos-primera-parte-aad90f30aa35

les recomiendo leer esté artículo.

Pienso que 6 minutos se quedan cortos para explicar DDD. En este caso, hay todo un sumario de terminlogías y conceptos que no están ligados puramente a arquitectura.

Sería espectacular tener un curso aplicado únicamente a DDD.

Realmente estas clases son muy buenos pero nos deja cortos para poder pensar en asumir el rol de arquitecto en una empresa.
Parecen cursos de introduccion pero propongo una carrera de Arquitecto de software en platzi.

Patrones: Diseño orientado al dominio

Se guía la aplicación y diseño a través del uso del lenguaje común entre el negocio y el desarrollo. Se trata de modelar el concepto y no tanto en especificar si es un servicio, factory o otro tipo de patron.

Los Contextos delimitados: (bounder context) Busca modularizar el sistema, estos contextos tratan de buscar en donde el lenguaje cambia de sentido.

Se concentra much en trabajar con el negocio y entender profundamente cual es el lenguaje que usan. Hay mucho valor en la semántica y mucho valor en la forma que se diseña y se conecta VS la forma en la que el negocio piensa.

------------ Diseño orientado al Dominio

• El diseño orientado al dominio genera módulos que se puedan desplegar por separado

• Guiar la aplicación através del uso del lenguaje común entre el negocio y el desarrollo

• Concentrar en ello las aplicaciones y no en el detalle técnico. Dice que se debe intentar modularizar la aplicación en Bounded Context.

• Tratan de encontrar donde el lenguaje cambia de sentido -> bounded context

• En el contexto de ventas el significado de producto es otro en comparación con el significado de inventarios.

• Aprovecha la separación semántica (propuesta por el negocio) para así separar nuestra aplicación

Me gustaría trabajar algunos de los ejemplos para entender mejor la teoría.

Dominio
Es toda la informacion del negocio, del problema que queremos resolver, es la corazon de nuestro DDD.

Ubiquitous Language
Es la comunicación efectiva entre los desarrolladores y los expertos del dominio. Un lenguaje común, que sea representado en el dominio, tanto como en los bounded contexts(subdominios), para asi lograr desarollar un software con los objetivos bien claros

Para mi es muy poco claro

Lo que se hace en un diseño orientado al dominio es llevar la aplicación mediante el uso de un lenguaje común entre el negocio (cliente) y el desarrollo del software (arquitecto/desarrollador). Esto va más allá de simplemente estar concentrado en detalles técnicos.

Su atención va completamente al problema relevante y ayuda a identificar una arquitectura para informar sobre las herramientas que se usarán en el desarrollo del software. Es una arquitectura con un lenguaje común, no solo técnico. Una arquitectura que todos puedan entender.

Patrón de arquitectura Diseño orientado al dominio
Guía la aplicación y el diseño a través del uso del lenguaje común entre el negocio y el desarrollo.
Buscar modularizar el sistema a través de contextos delimitados

Diseño Basado en dominios

No entendí la explicación, ¿En que casos necesito aplicar esto? ¿En todos? Y, con lo del lenguaje común entre la aplicación y el negocio, ¿Se refiere a representar el funcionamiento del negocio con los diferentes componentes de la aplicación?

¿Saben si existe algun curso en cualquier lenguaje que profundice en diseño orientado al dominio?
Quisiera implementar este tipo de diseño en un proyecto personal pero aun no logro comprender como llevar esta teoría a código.

Las explicaciones muy buenas pero, no estaría mal que en los ejemplos fueran sobre algunas aplicaciones reales, y quizá un poco más a detalle de como se formó dicha aplicación con este patrón.

Saludos!!!

Arquitectura con N Capas orientada al dominio propuesta por microsoft en el libro: Guía de Arquitectura de N-Capas orientada al Dominio con .NET 4.0

🤖🤖🤖
Diseño orientado al dominio
Lo que hacemos es guiar nuestra aplicación y el diseño a través del uso del lenguaje común entre el negocio y el desarrollo. El obtener ese lenguaje del negocio y el poder hacer aplicaciones que estén concentradas en eso mucho más que lo que están concentradas en detalles técnicos. Va más allá de una sola aplicación, nos dice que busquemos modularizar nuestro sistema a través de los bounded context, que tratan de encontrar dónde el lenguaje cambia de sentido.

El DDD más que una arquitectura es una forma de diseñar (vaya la redundancia). Es complicado de entender, pero en esencia consiste en que separes los componentes/modulos de tu desarrollo de acuerdo a como lo hace también el negocio que quieres modelar.
El ejemplo de los usuarios es el más completo, pues para una sección de la aplicación el usuario significa email y contraseña. En otro es comprador, proveedor, dueño, etc.
La idea principal de usar DDD es diseñar la lógica de negocio de la aplicación completamente aislada de la lógica de la implementación. Por ejemplo, es irrelevante saber que se usará JS o C# si ni siquiera saber que es lo que harás ni como lo harás

Este patrón es muy interesante ya que lleva un buen grado de coordinación, primero se separa el sistema en partes dentro de un contexto limitado y luego se las coordina.

Muy claras las explicaciones!

Mucha teoría pero nada de código ^^. 😦

Veo este patrón ciertamente conectado con la experiencia de usuario, cosa que está siendo muy relevante en la actualidad.