Muy buenas y bienvenidos a este vídeo donde vamos a hablar de la Screaming Architecture, propuesta por Robert C. Martin en Clean Architecture. Este principio de diseño lo que viene a decirnos es que la manera en la que organizamos las carpetas y las nombramos en nuestro proyecto software debe gritar, de ahí la palabra screaming, cómo está modelado nuestro negocio. Por ejemplo, si estamos trabajando en una agencia de viajes, probablemente nuestro negocio estará organizado en cosas como tour turístico, vuelos, hoteles, etcétera. En el caso de Eurmes, lo organizamos de una manera en la que tenemos que gritar el dominio propio, que suele tener que ver con academia, exámenes, parte práctica, parte teórica, etcétera. Vamos a ver directamente cómo está construido el backend de Eurmes para ver cómo cumplimos con este principio de diseño. Bien, lo primero que vemos al aterrizar en el backend de Eurmes es que ya nada más los nombres de las carpetas nos están gritando ese dominio: vemos academia, exámenes, favoritos, idiomas de aprendizaje, etcétera. Entonces, más o menos leyendo los nombres de las carpetas, ya vemos un poco de qué va el dominio de negocio sobre el que estamos trabajando. Si nosotros abrimos, por ejemplo, la parte de academia, a su vez vemos subcarpetas que también definen el dominio de negocio, por ejemplo teoría, práctica, autoría del contenido, etcétera. Sin embargo, si expandimos exámenes, lo que vemos son carpetas que no tienen nada que ver con el negocio, sino que son directamente artefactos software; concretamente son artefactos software de la arquitectura hexagonal. Entonces nosotros tenemos que saber a partir de qué momento dejamos de dividir por áreas de negocio y empezamos a dividir por conceptos más asociados al mundo software. En este caso, yo he decidido dividir academia en subáreas de negocio porque academia tiene suficiente grosor y suficientes áreas como para subdividir academia en espacios muy bien delimitados en cuanto a su frontera, o sea, que las fronteras estén muy bien delimitadas. Sin embargo, exámenes es un producto que todavía es joven y no ha crecido lo suficiente como para subdividirlo en más subáreas de negocio, y por eso tiramos directamente con artefactos software. Vamos a ver un ejemplo en el que hemos dividido demasiado rápido la carpeta en artefactos software en lugar de seguir subdividiendo en áreas de negocio. Nosotros vemos la carpeta de autorización y vemos que ya en un primer nivel estamos dividiendo por conceptos propios de la arquitectura hexagonal y no tanto de el negocio en el que estamos trabajando. Si nosotros expandimos application y los use cases, vemos que tenemos muchas cosas mezcladas aquí dentro: tenemos la eliminación de cuenta, el cambio de password, confirmar que quieres transformar una cuenta de invitado a una cuenta real, eliminar cuenta de invitado, obtener los roles de un usuario, saber si una sesión es válida, revocar sesiones, crear sesiones, crear cuentas... Lo que vemos que hay muchísimas cosas mezcladas bajo el mismo dominio de autorización. Si yo ahora le pido a alguien del equipo que vigile el tema de sesiones de usuario, porque un usuario puede entrar en el ordenador pero no puede entrar en el móvil a la vez, tengo que estar buscando en cada uno de estos archivos en qué momento estoy revocando sesiones o asignando sesiones, etcétera. Y esto tiene un coste a nivel temporal y de mantenimiento a largo plazo si el equipo crece. Entonces, vamos a ver una versión más moderna de este backend para ver cómo se puede distribuir de mejor manera el módulo de autorización. Bien, pues lo primero que podemos apreciar en el módulo de autenticación nuevo es que ahora está subdividido nuevamente en áreas de negocio. Tenemos el caso de acceso, que en este caso incluye todo lo que es login, recuperar cuenta, crear cuenta, etcétera; es decir, todo lo que pasa fuera de la aplicación sin haber entrado, sin haber accedido dentro de la aplicación. Después tenemos la parte de credenciales, que aquí tenemos por ejemplo cambiar el email, el password o a lo mejor en el futuro queremos añadir códigos de recuperación, doble autenticación, etcétera. Todo el tema de cuentas de invitado también lo separamos porque es un caso especial en el que queremos que los usuarios vean nuestro producto sin tener que pasar por todo el proceso de elegir un email, poner código de validación, elegir password, etcétera, sino que queremos una vía más rápida para reducir la fricción y que conozca nuestro producto. También tenemos el tema de sesiones y de gestión de identidad. Entonces, si yo ahora le digo a alguien: "Oye, resulta que hay un fallo porque una persona no puede entrar al móvil y al ordenador a la vez; o entra en uno o en otro", ¿dónde vas a buscar tú directamente? Pues probablemente en la carpeta de sesiones, donde tienes los diferentes use cases que tienen que ver con crear sesiones. Si yo te digo ahora: "Oye, en el login, no sé, hay usuarios que reportan que no pueden entrar", ¿a dónde voy a ir? A access, porque tiene que ver con el acceso. Lo mismo con crear cuenta o con otros casos. Bien, pues a modo de recapitulación, en este vídeo lo que hemos visto es que no siempre es adecuado empezar a organizar nuestro proyecto por artefacto software, sino que es mejor empezar a organizarlo gritando el dominio de negocio sobre el que estamos trabajando. Las ventajas de este enfoque es que preparamos nuestro proyecto para microservicios y además reducimos la fricción de nuevos miembros del equipo, dado que el proyecto no está organizado por artefacto software complejo, sino que está más organizado por negocio, que es algo bastante human friendly. Aparte de esto, también, si tocamos un área de negocio, bien sea crearla, modificarla o eliminarla, es probable que, al estar separada de otras áreas, no haya efectos colaterales, o por lo menos los reduzcamos. Como desventajas de este enfoque, tenemos que hay que tener mucha disciplina de equipo, sobre todo para respetar la división por áreas de negocio, y también suele haber algo de dificultad al clasificar nuevas cosas que van saliendo en alguna de las áreas funcionales. Normalmente, en este caso, lo que hacemos es dejar crecer mucho una determinada área funcional y, cuando hay suficiente contenido, nosotros podemos ver de manera más fácil en qué fronteras se subdivide. No preocuparnos al principio por hacer un sobreesfuerzo de dividir un módulo en submódulos, sino esperar a que un módulo crezca lo suficiente como para que grite: "Oye, divídeme en diferentes submódulos porque soy demasiado grande y abarco demasiadas cosas". Bueno, espero que te haya gustado este vídeo y nos vemos en otro vídeo.