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.
Introducción al curso
Diseño y Documentación de Arquitectura de Software
Atributos de calidad
Atributos de Calidad en Sistemas: Definición y Medición
Idoneidad Funcional: Completitud, Exactitud y Pertinencia
Eficiencia de Ejecución en Sistemas Informáticos
Compatibilidad en Sistemas: Interoperabilidad y Coexistencia
Subcaracterísticas de Usabilidad en Desarrollo de Software
Confiabilidad de Sistemas: Madurez, Disponibilidad, Resiliencia y Recuperación
Seguridad de Usuarios en Desarrollo de Software
Subcaracterísticas de Mantenibilidad en Sistemas de Software
Medición de Adaptabilidad en Sistemas de Software
Relación y Tensión entre Atributos de Calidad en Sistemas de Software
Atributos de Calidad en Arquitectura de Software
Patrones de arquitectura
Patrones de Arquitectura Monolítica y Distribuida
Modelo Vista Controlador: Separación de Responsabilidades en Aplicaciones
Arquitectura de Capas: Diseño y Comunicación entre Niveles
Patrones de Arquitectura Orientada a Eventos y Event Sourcing
Patrón de Arquitectura MicroKernel y su Implementación en IDEs
Arquitectura "Comparte Nada": Optimización y Procesamiento de Datos
Patrón de Microservicios en Arquitectura de Software
Patrón CQRS para Separación de Consultas y Comandos
Arquitectura Hexagonal: Diseño y Aplicación Práctica
Diseño Orientado al Dominio: Conceptos y Aplicaciones Prácticas
Patrones de Arquitectura para Aplicaciones Escalables y Modulares
Patrones de Arquitectura en Proyectos de Crecimiento Empresarial
Diseño de una arquitectura
Diseño de Arquitecturas a Medida: Herramientas y Estrategias
Tipos de Conectores en Arquitectura de Software
Conectores Asíncronos y Sincrónicos: Implementación y Uso Práctico
Diferencias entre Enrutadores y Difusores en Comunicación de Mensajes
Conexión de Productores y Consumidores con Colas de Mensajes
Framework de Diseño Orientado a Atributos: Escenarios y Tácticas
Tácticas para Mejorar la Disponibilidad de Sistemas
Tácticas para Mejorar la Disponibilidad del Sistema
Tácticas para Mejorar la Mantenibilidad del Software
Prevención de Efectos Dominó en Mantenibilidad de Software
Estrategias para Mejorar la Eficiencia de Ejecución en Sistemas
Tácticas de Seguridad Informática para Detectar, Resistir y Recuperarse de Ataques
Estrategias para Mejorar la Capacidad de Prueba de Software
Tácticas de Usabilidad en Diseño de Interfaces de Usuario
Validación de Arquitectura con ATAM y Métricas de Calidad
Diseño de Arquitectura para Startups y Empresas Escalables
Modelado y documentación de arquitectura
Documentación Efectiva de Arquitectura de Software
Sincronización de Modelos de Arquitectura y Código Fuente
Evaluación de Atributos de Calidad en Arquitectura de Software
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
El diseño orientado al domino no lleva a orientar nuestra aplicación y su diseño a partir del lenguaje del negocio.
Aportes 30
Preguntas 2
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.
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.
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.
Me gustaría trabajar algunos de los ejemplos para entender mejor la teoría.
------------ 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
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
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
✅
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
Increible que de un tema tan importante como DDD, solo se tenga este video de 5 minutos.
🤖🤖🤖
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.
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.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?