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 482215019 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
2182215019 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