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
Introducción al curso de Profesional de Arquitectura de Software
Atributos de calidad
Definición
Atributos: Idoneidad funcional
Atributos: Eficiencia de ejecución
Atributos: Compatibilidad
Atributos: Usabilidad
Atributos: Confiabilidad
Atributos: Seguridad
Atributos: Mantenibilidad
Atributos: Portabilidad
Tensiones entre atributos
Analizando PlatziServicios
Patrones de arquitectura
Patrones monolíticos vs distribuidos
Patrones: Modelo Vista Controlador
Patrones: Capas
Patrones: Orientado a eventos / Provisión de eventos.
Patrones: Microkernel - Plug-ins
Patrones: Comparte-nada
Patrones: Microservicios
Patrones: CQRS
Patrones: Hexagonal - Puertos y adaptadores
Patrones: Diseño orientado al dominio
Combinando patrones de arquitectura
Analizando nuevamente PlatziServicios
Diseño de una arquitectura
Pararse en hombros de gigantes
Herramientas y partes de un diseño: Tipos de conectores
Conectores: Llamado asincrónico / sincrónico. Modelo Cliente servidor.
Conectores: Enrutador, difusión
Conectores: Pizarra, repositorio, colas, modelo PUBSUB
Escenarios y tácticas
Escenarios: Disponibilidad, detección, reparación
Escenarios: Reintroducción y prevención
Escenarios: Mantenibilidad
Escenarios: Prevenir efectos dominó y diferir enlace
Escenarios: Eficiencia de ejecución
Escenarios: Seguridad
Escenarios: Capacidad de prueba
Escenarios: Usabilidad
Validar las decisiones de diseño: Arquitectura en evolución
Último análisis a PlatziServicios
Modelado y documentación de arquitectura
Cómo comunicar la arquitectura: Vistas y Puntos de vista
Documentación vs implementación
Conclusiones del curso
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 23
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.
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.
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
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.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?
o inicia sesión.