Screaming Architecture
Audiocurso de Frameworks y Arquitecturas Frontend: Casos de Estudio
Contenido del curso
Giuliano De Leonardis
Miguel Ángel Durán García
ProfesorGiuliano De Leonardis
Adriel Francesco Pezo Vizcarra
Miguel Ángel Durán García
ProfesorBeicker Jesus Zambrano Escalona
Cesar Eduardo Valle Pino
Miguel Ángel Durán García
ProfesorIvan Camilo Buitrago Buitrago
Juan David Casseres Rodríguez
Miguel Ángel Durán García
ProfesorFélix Alejandro Zelaya Orellana
Johanna Apure Canónico
Alvaro Rafael Guete Puello
Screaming Architecture
Lo fácil que suena y lo complicado que es luego en la practica. :)
Como muchos aspectos de la vida profesor.
La programación es un área de desenvolvimiento del ser humano, y tal desenvolvimiento es mejor (para nosotros y los demás) que tenga una estructura ordenada y coherente... tal cual una cita literaria, jejeje : )
Buena idea. Un dolorcito de cabeza hoy, pero a futuro nos ahorrará problemas y dinero
Totalmente, muy importante para hacer el código mantenible y escalable en el futuro!
Hola amigos, se me estaba haciendo algo dificil entender como implementar todo esto, personalmente se me hizo un poco corto el video pero luego de buscar un rato acá les dejo este recurso que creo que profundiza un poco más sobre como implementar esto especificamente en React.js
https://profy.dev/article/react-folder-structure#exit-group-by-features
Intentando comprender Clean Architecture, inicie un proyecto separándolo en módulos diferentes, colocando una carpeta para cada módulo y dentro de cada módulo seguir un MVC. Desconocía el término Screaming Architecture, que gracías a este curso lo he conocido, con el tiempo me ha facilitado la existencia guiarme por los nombres de los módulos, sobretodo cuando hay que realizar actualizaciones sobre módulos que tienes meses de no trabajar.
Me alegro que hayas aprendido algo nuevo! :)
El patrón de arquitectura "Screaming Architecture" se enfoca en organizar el código alrededor de los objetos de negocio, en lugar de seguir una estructura convencional de carpetas como "components", "reducers", "actions", "api", etc.
En lugar de eso, se utilizan carpetas que representan los objetos de negocio, como "products", "users", "orders", etc. Dentro de estas carpetas se encuentran las implementaciones correspondientes a ese objeto de negocio, según el stack tecnológico elegido.
La idea detrás de este patrón es poner el negocio y el valor del producto en un nivel superior de la jerarquía, de modo que la tecnología utilizada esté al servicio del negocio, y no al revés.
Esto significa que la estructura del código refleja directamente la estructura del negocio, lo que facilita la comprensión y el mantenimiento del código a largo plazo.
Algunas ventajas de este enfoque:
En resumen, Screaming Architecture pone el énfasis en la estructura del negocio, en lugar de la estructura técnica, lo que facilita la comprensión, el mantenimiento y la escalabilidad del código a lo largo del tiempo.
Esto sería algo como DDD?
Están relacionados. Pero podrías hacer Screaming Architecture sin usar DDD. Pero si usas DDD, tendrás que seguir Screaming Architecture.
Genial, voy a implementarlo!
Yo lo aplicaría para las vistas, el nombre de las carpetas definen a que rol pertenecen, pero en caso de que se comparta alguna vista a 2 roles ya habría que basar el nombre de las carpetas a lo que gestionan: productos, roles, publicidad, etc
Totalmente de acuerdo con el enfoque de Screaming Architecture. La idea central es que, al observar la estructura de un proyecto, debe gritar de qué se trata el negocio, no qué tecnologías usa.