2215019 ODA! DDD Objetivo Desarrollar aplicaciones complejas establiendo modelos de un dominio problemético, conseguir un modelo orientado a objetos que refleje el conocimiento de un dominio dado y que sea completamente independiente de cualquier concepto de comunicacién. Prerrequisitos Domain: Una esfera de conocimientos, influencia 0 actividad. Es el drea tematica a la que el usuario aplica un programa es el dominio del software, Modelo: Un sistema de abstracciones que describe aspectos seleccionados y puede ser utilizado para resolver problemas relacionados con ese dominio. Lenguaje omnipresente: Lenguaje estructurado entorno al modelo de dominio y utlizado por todos los miembros del equipo dentro de un contexto limitado para conectar todas las actividades del equipo. Qué es DDD.- (Domain-Driver Design) E1 Disefio Guiado por el Dominio es un conjunto de patrones para crear aplicaciones enpresarial< Es el vinculo intimo entre el modelo y 1a implementacién 1o que hace que el modelo sea relevant » generated by haroopad fl:13C:/SIASWIDocumentos!2017/DocumentosiLectua/Calldad de Software/000.hxml 482215019 ODA! Implementacién: Arquitectura de Software: identifica los requisitos que producen un impacto en la estructura del sistema y reducir los, riesgos asociados con la construccién del sistema, soportar los cambios futuros * Mostrar 1a estrucutra del sistema. * Realizar los casos de uso. * Ocuparse de los requisitos funcionales y de calidad. * Determinar el tipo de sistema a desarollar. * Determinar los estilos arquitecturales que se usarén. * Tratar las principales cuestiones transversales. Observaciones.- Tener arquitectura sobre la linea base, posteriormente iré madurando, considerando la arquitectura de despliegue, el estilo arquitectural, las tecnologias selecionadas, los requisitos de calidad y las desiciones transversales. + Tipo de Aplicacién.- Web + Estructura Légica (Capas).-Presentacién, Negocio, Datos, Infraestructura * Estructura Fisica (Niveles).- Presentacién, Negocios, Datos. + Riesgos a afrontar.- Seguridad, Rendimiento, Flexibilidad + Teconlogias a usar API Rest, Angular Casos de uso Requisitos funcionales y no funcionales. Restricciones tecnolégicas y de disefio en general Entorno de despliegue propuesto. Disefio de Arquitectura Casos de uso importantes. + Esquema del Sistema, + Idenificar riesgos. + Arquitecturas Candidatas. Objetivos de ta iteraccién, Aplicacién Web SPA (Single Page Apps). Arquitectura en capas, Dividido en Backend ASPNET con Rest API Frontend Angular fl:13C:/SIASWIDocumentos!2017/DocumentosiLectua/Calldad de Software/000.hxml generated by haroopad 2182215019 ODA! Aspectos del DDD Esquema de comunicacién de Arquitectura Comunicacién con los expertos del dominio Il Arquitectura y Disefio-> Acelera el desarrollo correcto -> Desarrollo > Feeback de desarrolladores > Mejora del Deisefio y la Arquitectura, Lenguaje ubicuo Se requiere tener un lenguaje comin, que permita comunicarse entre los expertos del deominio y los desarrolladores, asi como entre los desarrolladores, evitar tener diferentes interpretaciones de conceptos o la miltiple representacién de un mismo concepto. Behavior Driven Development (BDD) Descripcién de los requisitos como un conjunto de pruebas ejecutables de forma automatica. Ayuda ala transferencia de conocimiento al provocar que los principales conceptos de! dominio presentes en los requisitos, pasen directamente al c6digo, destacando su importancia dentro del dominio y creando un contexto o base para la construccién del modelo. Test Driven Development (TDD) Consiste en desarrollar un conjunto de pruebas que sirven como especificacién y justificacién de la necesidad de crear un coponente para implementar una determinada funcionalidad. Estas pruebas permiten definir la forma del propio componente e indagan en las relaciones de este con otros componentes del dominio, lo que fomenta el desarrollo del modelo. Capas Son agrupaciones horizontales l6gicas de componentes de software que forman la aplicacién. Ayudan a diferenciar entre los diferentes tipos de tareas a ser realizadas por los componentes, ofrenciendo un disefio que maximiza la reutilizacién y, especialmente, la mantenibilidad. Se trata de aplicar el principio de Separacién de Responsabilidades (SoC - Separation of Concens Principle), dentro de una arquitectura, Disefio de Capas Estricto generated by haroopad fl:13C:/SIASWIDocumentos!2017/DocumentosiLectua/Calldad de Software/000.hxml a8