Empecemos con todo este curso hablando de dos conceptos
que quizás hayas escuchado cuando estructuramos una aplicación.
El primero de estos conceptos es la arquitectura de tres capas.
Y en esta arquitectura lo que vamos a tener es
una capa de presentación que es la que va a interactuar con el usuario.
Esta capa de presentación podría ser web, podría ser móvil,
podría ser desktop, no interesa.
Y esta capa de presentación va a interactuar
con algo que vamos a llamar el dominio.
Y en este dominio va a estar la lógica de negocio,
validaciones, cálculos.
Y finalmente este dominio va a tener que acceder a una capa de datos.
Y esa capa de datos es la que normalmente se va a comunicar
con una base de datos relacional, como Postgres, como SQL Server,
pero también podría ser algo no SQL.
Y esta es una arquitectura y es una recomendación muy común
a la hora de organizar aplicaciones.
Pueden haber más o pueden haber menos capas,
pero tres capas es lo que normalmente vemos en la práctica.
La segunda forma de estructurar una aplicación
que quizás hayas visto se llama modelo vista controlador.
Y en el modelo vista controlador vamos a tener algo así.
Vamos a tener igualmente una vista
que es la que se encarga de la interacción con el usuario
y las peticiones que se generen en esta vista
van a llegar a un controlador.
Y a mí me gusta mucho comparar el controlador
con una especie de 10 en un equipo de fútbol
donde ese controlador es el que sabe
cómo empezar a repartir esas solicitudes
que lleguen a la vista.
Esas solicitudes normalmente van a ser manejadas por un modelo,
ese modelo también va a tener lógica de negocio,
va a tener acceso a datos.
Dependiendo de la implementación,
puede ser que haya una interacción entre el modelo y la vista,
pero esta es la estructura básica que vamos a ver
en un patrón MVC.
Sin embargo, estos enfoques,
la arquitectura de tres capas y el patrón MVC
tienen unas limitaciones.
La primera es que es un desarrollo centrado
en la base de datos.
Al final, todo converge en una base de datos
normalmente relacional,
no relacional también podría ser,
pero todo está enfocado a eso.
Tanto así que lo que uno primero diseña
es la base de datos.
Por otro lado, notas que la lógica de negocio
depende totalmente de la persistencia.
Es como que casi que si la lógica de negocio no existiera,
sin ese lugar donde se van a almacenar los datos.
La tercera limitación es que si hay otras integraciones,
no es claro dónde tienen que ir.
Es decir, si yo tengo que hacer algo con la interfaz gráfica,
pues es claro que tengo una capa de presentación
o tengo una capa para la vista.
Si necesito lógica de negocio, yo sé que va en el dominio.
Si tengo que hacer algo con la base de datos,
como por ejemplo, incluir una nueva columna
o incluir un nuevo tipo de dato,
pues yo sé dónde tengo que hacer esa modificación.
Pero si tengo integración con la base de datos,
o tengo integraciones, por ejemplo, con una red social,
con un sistema de archivos,
aquí ya empieza a ponerse la arquitectura
un poco más borrosa,
porque no es explícita acerca de esto.
Y la limitación número cuatro
es que la lógica de negocio a veces,
o quizás muchas veces, tiende a filtrarte.
No sé si te haya ocurrido, pero a mí sí.
Y es que muchas veces uno empieza a notar lógica de negocio
que está, por ejemplo, en la presentación.
Entonces tú ves una interfaz gráfica
y ves, por ejemplo, un botón,
y en el clic de ese botón te encuentras lógica de negocio,
cuando debería ir en una capa diferente.
Y esto es un problema porque no permite reutilizar fácilmente.
Entonces, a veces por tomar atajos,
a veces por confusión porque no es clara la arquitectura,
la lógica tiende a filtrarse.
Y ante estas dificultades es que surgen las arquitecturas limpias
como una alternativa para organizar mejor la lógica de negocio
y poder tener claras esas dependencias
que en una arquitectura de tres capas
o en un patrón MVC no son tan claras.
Entonces, sobre eso vamos a estar hablando
y mi recomendación es que a continuación
dejes un comentario donde me cuentes
si ya conocías la arquitectura de tres capas o el patrón MVC
y si ya los habías aplicado antes.
Nos vemos en la próxima lección.