Scribd
Cargar
92 vistas9 páginas

Arquitectura Convencional de Software

Este documento describe la arquitectura de software convencional de hace 50-60 años. Consistía en monolitos con código desestructurado y muchas interdependencias entre componentes, lo que hacía el software difícil de mantener. Se usaban clases anémicas y los componentes estaban fuertemente acoplados, llevando a una arquitectura rígida.

Cargado por

Antony
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
92 vistas9 páginas

Arquitectura Convencional de Software

Este documento describe la arquitectura de software convencional de hace 50-60 años. Consistía en monolitos con código desestructurado y muchas interdependencias entre componentes, lo que hacía el software difícil de mantener. Se usaban clases anémicas y los componentes estaban fuertemente acoplados, llevando a una arquitectura rígida.

Cargado por

Antony
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

INTRODUCCIÓN

ARQUITECTURA
CONVENCIONAL
Daniel Blanco Calviño
POCOS REQUISITOS
Hace 50 o 60 años la mayoría del software era mucho más sencillo que hoy en día.

Necesidad de automatizar tareas.


CRUDs simples.
etc.

Esto llevó a software del siguiente tipo.

Pequeños scripts de automatización.


Monolitos.
Muchas interdependencias entre los componentes internos.
Código desestructurado y difícil de mantener.

MONOLITOS

MONOLITOS - CAPAS DEL SOFTWARE

MODELO ANÉMICO

Clases que no almacenan lógica, únicamente


datos.
Muy comunes en CRUDs.
Lógica necesaria se implementa en servicios.
Considerado un antipatrón de diseño

DEPENDENCIAS ENTRE COMPONENTES


En monolitos y arquitecturas convencionales es muy común tener componentes muy
acoplados. El siguiente escenario es muy común:

Componente A necesita un componente Z. Lo implementamos.


Surge una necesidad de ciertas funcionalidades de Z en el componente B.
Pasa lo mismo en C, D...
Con el tiempo, las necesidades evolucionan, y se adapta Z para que abarque todo lo
que necesiten A, B, C y D.

¡Este tipo de decisiones hacen que nuestra arquitectura sea rígida y difícil de modificar!

INTRODUCCIÓN

ARQUITECTURA
CONVENCIONAL
Daniel Blanco Calviño

También podría gustarte