Lineamientos para el desarrollo

de nuevas aplicaciones
Arquitectura UTP

Febrero - 2020
ESTRUCTURA

1. Lineamientos Front end

2. Lineamientos Back end
3. Lineamientos para la exposición de APIS públicas
4. Lineamientos Base de Datos
5. Stack tecnológico
6. Buenas prácticas
LINEAMIENTOS FRONTEND
LINEAMIENTOS DE FRONT END

Consideraciones Generales

 Todo desarrollo debe seguir el stack tecnológico establecido.

 Todo desarrollo debe considerar la estructura de capas establecido.
 Todo desarrollo debe ser Stateless
https://medium.com/@rachna3singhal/stateless-over-stateful-applications-73cbe025f07
 La autenticación de usuarios debe ser via Oauth2
 El código generado de ser totalmente estático (CCSS, JS, Imágenes, html, etc)
 Debe cumplir con las reglas de desarrollo seguro y no tener vulnerabilidades que se encuentren en el TOP10 de OWASP.
 Las fuentes deben ser versionadas en el repositorio BitBucket de UTP, no se realizan despliegues a DEV, QA y PROD de
artefactos no versionados y custodiados por UTP.
ARQUITECTURA DE FRONTEND
La capa de dominio no debería
saber de dónde viene la data.
En ésta capa tenemos los

Estructura de Capas
resolvers que obtendrán los
datos remotos del backend.

Presentation Layer Domain Layer Data Layer Backend

REPOSITORY
PRESENTER USER CASE

DATASOURCES

Devices Layer

LOCATION

VIEW REDUCER
NOTIFICATION

Las vistas solo implementan el patrón de

Vista pasiva. En ésta capa usaremos la
Cada Caso de Uso es un componente reusable que API de Android / iOS como
El presentador sirve como intermediario
ejecuta una lógica de negocios en específico. los sensores, alarmas,
entre las vistas y la lógica de negocio (capa
Obtiene los datos de la capa de datos o la capa del notificaciones, ubicación
de dominio).
dispositivo, ejecuta la lógica de negocios y envía el del usuario y más.
El presentador maneja las interacciones de
resultado a los reducers.
los usuarios, invocan la lógica adecuada y
Los reducers actualizarán el estado de la
envían los datos a la interfaz de usuario para
aplicación, luego el store emitirá esos cambios en la
su representación.
capa de presentación.
LINEAMIENTOS BACKEND
LINEAMIENTOS BACKEND

Consideraciones Generales
 Todo desarrollo debe seguir el stack tecnológico establecido.
 Todo desarrollo debe considerar la estructura de capas establecido.
 Todo desarrollo debe ser Stateless
https://medium.com/@rachna3singhal/stateless-over-stateful-applications-73cbe025f07
 Todo desarrollo debe ser dockerizado.
 Todo desarrollo debe capturar y escalar las excepciones, desde la especifica a la general.
 Considerar construcción de log detallado para el buen registro y monitorio de eventos.
 Seguir el patrón de desarrollo SOA basado en microservicios.
 La comunicación entre microservicios debe ser vía servicios Rest y deben ser Api restfull.
 Todos los servicios Rest deben contar con su documentación en formato Swagger, cumpliendo los principio de Open API
3.0 (https://swagger.io/specification/ https://www.openapis.org/)
 Toda API REST expuesta son privadas, no se expone ninguna API de forma pública.
 No se debe persistir la sesión, ni la validación de token para autenticar un usuario dentro del backend.
 No debe recibir ningún token, ni gestionar la autenticación las API’s de los microservicios.
 No debe persistir imágenes, archivos, ficheros planos de más de 5 MB y no de una duración mayor de 10 minutos.
 Debe cumplir con un code coverage de pruebas unitarias de al menos 80% (SonarQube).
 No puede tener deficiencias en la calidad de código Critical, Block, code smell con (SonarQube).
 Debe cumplir con las reglas de desarrollo seguro y no tener vulnerabilidades que se encuentren en el TOP10 de OWASP.
 Las fuentes deben ser versionadas en el repositorio BitBucket de UTP, no se realizan despliegues a DEV, QA y PROD de
artefactos no versionados y custodiados por UTP.
LINEAMIENTOS DE BACKEND

Estructura de Capas

Cloud On-premise
APPLICATION 123

MULTIPLE
FRONT END 123 D
SECURITY BFF APP LOGIC DATABASE
O C
M O
A R
I E
N
APPLICATION ABC D
C A
MULTIPLE
O T
FRONT END ABC SECURITY BFF APP LOGIC DATABASE R A
E
L
L A
A Y
APPLICATION XYZ Y E
MULTIPLE E R
FRONT END XYZ R
SECURITY BFF APP LOGIC DATABASE

Es la capa que interactúa Es la capa que tiene la lógica de la aplicación a

con los usuarios finales a
través de una: web, móvil,
etc.
Es la capa de negocio que Es la capa donde se
desarrollar. tiene como objetivo encuentran las fuentes de
Cuenta con base de datos propias y soluciones
exponer los servicios de la datos, ya sea base de
orientadas a dicha aplicación. base de datos. datos, storage, etc
Cuenta con una mini arquitectura interna. Estos servicios son
Se recomienda que se tenga una capa de agnósticos a la aplicación.
experiencia o BFF (backend for frontend) para
los diferentes canales.
LINEAMIENTOS BASE DATOS
LINEAMIENTOS DE FRONT END

Consideraciones de motores de BD

 Todo desarrollo debe seguir el stack tecnológico establecido.

 Servicios de BD relacionales de AWS RDS (MySql, PostgreSQL)
 Servicio PaaS de AWS de Mongo DB (DocumentDB)
 Se debe versionar el script de creación de usuarios, esquemas, tablas y objetos en general en un repositorio BitBucket que
gobierne UTP.
 No se realiza el pase a los entornos de DEV, QA y PROD si no se tienen los script correctamente versionados.
LINEAMIENTOS APIS PUBLICAS
LINEAMIENTOS DE FRONT END

La exposición de Apis públicas tiene como objetivo el poder consumir recursos desde las aplicaciones Front
End o cualquier otro consumidor externo.

Consideraciones Generales
 Se debe exponer API’s publica únicamente a través del servicio de AWS Api Gateway
 La exposición debe ser autorizada y autenticada vía Ouath2
 Todos los servicios Rest deben contar con su documentación en formato Swagger, cumpliendo los principio de Open API
3.0 (https://swagger.io/specification/ https://www.openapis.org/)
 Api Gateway será el único canal de integración con las API’s Rest de los microservicios Backend.
STACK TECNOLOGICO
STACK TECNOLÓGICO

Aplicaciones

Datos

DevOps

Plataforma
ARQUITECTURA DE FRONTEND

BUENAS PRÁCTICAS Y PATRONES

BUENAS PRÁCTICAS

Test Driven Development (TDD)

Mejora tu código Escribe una

sin cambiar el 3 1 prueba, mirala
comportamiento fallar

TEST DRIVEN DEVELOPMENT

TDD
● Mejora el diseño del código.
● Minimiza la cantidad de código a escribir.
● Confianza.
● Permite un desarrollo más rápido.
2

Escribe suficiente
codigo para pasar
la prueba
BUENAS PRÁCTICAS

Principios S.O.L.I.D.
S.O.L.I.D. es el acrónimo de los 5 principios para el diseño de un programa orientado a objetos.

En ello mencionan la importancia de que cada clase debe tener una determinada función o trabajo a realizar, evitando sobrecargar
cada clase.

Del mismo modo cada objeto debería estar abierto a una extensión pero cerrado a modificaciones, esto lo logramos usando
interfaces. Evitando hacer futuros cambios sobre la misma clases y rompiendo posibles funcionalidades ya implementadas.

Finalmente, al momento de proveer dependencias a una clase, la creación de los mismos deben realizarse por un objeto o clase
externa, fuera de la clase en donde se requiera las dependencias. Aplicando ello, podemos proveer distintos tipos de dependencias o
los mismos(Singleton) según se requiera.

S O L I D
Single Open-Closed Liskov Interface Dependency
Responsibility Principle Substitution Segregation Inversion
Principle Principle Principle Principle
BUENAS PRÁCTICAS

Clean/Hexagonal Architecture
puntos de entrada core proveedores de data

REST APIs BASE DE DATOS

Clean Architecture es una filosofía de diseño de

software que separa los elementos de un diseño en
niveles de anillo. ENTITIES
La regla principal de la arquitectura limpia es que ARCHIVOS DE

-
SISTEMA
las dependencias de código sólo pueden provenir CASOS DE USO
de los niveles externos hacia adentro.
El código en las capas internas no puede tener
conocimiento de las funciones en las capas
externas. JOBS DISPOSITIVOS RED

CONFIGURACIÓN
BUENAS PRÁCTICAS

CSS Architecture

Estamos usando Atomic Design como arquitectura CSS.

El diseño atómico nos permite tomar sistemas de diseño complejos y descomponerlos en componentes más pequeños llamados
átomos. Entonces, es mucho más fácil para todos los involucrados en el proyecto ver qué partes del sitio se pueden reutilizar.

ATOMOS MOLECULAS ORGANISMO PLANTILLA PAGINAS

BUENAS PRÁCTICAS

Diagrama GraphQL

Payments
{ REST }

Mobile APP Academics

GraphQL nos permite disminuir la cantidad de { REST }
request que realiza el dispositivo móvil.
Esto es útil, ya que los request en dispositivos Web APP
móviles son muy costosos. People
{ REST }
Other Services GraphQL
como
Authentication
API Gateway
{ REST }
 Gracias
Arquitectura UTP