Apuntes Arquitectura de Software

ARQUITECTURA BUENA

Simple: Evita la complejidad y sea desacoplable

Understand: Entendible por el usuario respecto a sus capas

Flexible: Sea sincronizable con otras aplicaciones

Emergente: Tiene la posibilidad de crecer (evolucionar)

Testeable: Da la posibilidad de hacer pruebas

Mantenible: Permite recibir mantenimiento, correcciones, etc.

WWW.SONARCLOUD.IO/EXPLORE/PROJECTS

(Permite evaluar la calidad del software respecto a archivos maliciosos, entre otros)

Permite pruebas tangibles de software

Java Decompiler --> Se debe tratar de no ser evidente para evitar vulnerabilidades

SONARQUBE --> Permite realizar un análisis estático

Evidencia tangible: si el codigo hace lo que se propone

La cobertura en el código nos sirve para testear que nuestro código este haciendo correctamente sus funciones

ARQUITECTURA LIMPIA

Diseñada para los usuarios de la arquitectura (Habitantes). NO para arquitectos o maquinas.

Invertir en una arquitectura limpia:

-Costo/Beneficio: A menores costos de postimplementacion generara menor gasto y mayor beneficio.

-Minimizar costo: Minimizar costos en la creacion de software utilizando componentes "estandarizados" que cumplan las mejores practicas.

-Maximizar valor: Valor de apreciacion del cliente hacia el software.

-Maximo retorno de inversion (ROI):

-Enfocarse en lo escencial: para mandar mensajes

-Construido solo con lo necesario para funcionar

-Optimizado para su mantenibiidad

DESICIONES

Las desiciones en la creacion de un software deben ser argumentadas

Deben seguir los objetivos de negocio

Deben seguir un buen juicio basado en la experiencia y la realidad

-------------------------------------------------

Database Centric vs Domain Centric

DataBase Centric

UI(Logic Bussiness(Data Access-Database))

Domain Centric

(Presentacion (Application (Domain) ) Persistencia - Infraestructure) DataBase

Escential vs Detail

Dominio: Es lo escencial --> Es el caso de uso para el cual fue creado

Presentacion es detalle

Persistencia es detalle

---------------------------------------------------------

---------------------------------------------------------

Level 1: Contexto

Level 2: Containers

Level 3: Compknents

Level 4: Code

Descomposicion de dominios en componentes (UDM)

UDm: Describ elas fronteras de los limites de cada dominio

____________________________________________________________

ARQUITECTURAS CENTRADAS EN EL DOMINIO

ARQUITECTURA CENTRADA EN LA BD

-Los datos yacen en el centro de la organizacion.

-La interfaz de usuario, la logica empresarial y el acceso a los datos dependen de la base de datos.

-Es la parte escencial del sistema de forma natural. Todo va alrededor de la base de datos.

Desventajas: -Fue diseñado para un solo tipo de presentacion

-No es flexible ni agil, no es posible mover las partes por encontrase adheridas hacia arriba o hacia abajo.

-Todas las dependencias son hacia la base de datos

ARQUITECTURA CENTRADA EN EL DOMINIO

-El dominio y los casos de uso son escenciales.

-La presentacion y las bases de datos son dolo un detalle

-Todas las dependencias apuntan hacia el dominio

Tipos:

Arquitectura Hexagonal: La aplicación esta en el centro del sistema.

Arquitectura de complemento

Incluye puertos y adaptadores

Arquitectura Onion: Arquitectura en capas cuyo centro es el dominio rodeado por la capa de aplicacion

Externamente yace la capa de UI (persistencia y presentacion)

Se pueden probar aplicaciones sin UI y dependencias de BD

Arquitectura Limpia: Las entidades estan en el centro, rodeado por los casos de uso

La capa externa contiene puertos y adaptadores

Se adapta el nucleo a las dependencias externas con ayuda de los controladores y puertas de enlace y presentadores

Las 3 arquitecturas tiene como objetivo resolver los problemas se arquitecturas tradicionales y la separacion de preocupaciones.

Ventajas:

-Se enfoca en el dominio

-Menos acoplamiento

-Permite el Diseño guiado por el dominio (DDD) "Provee una estructura de practicas

...