Mejora tu código aplicando Clean Architecture 

Hola Ernesto, buenísima pregunta, yo tambien me la hice en su momento y la solución que encontré fue creando un módulo shared donde a través de un index.ts exporto los agregados que se puedan usar en otros módulos, digamos que un caso de uso que necesita hacer uso de un agregado que pertenece a otro módulo solo lo debería poder importar desde el módulo shared. Evidentemente es una regla que te creas como diseño de tu arquitectura. En caso de usar monorepos existen reglas que se pueden definir donde se especifica que tipo de modulo puede importar elementos del dominio de que otros módulos, en esa regla yo especifico que un módulo estandar(todos menos el shared) pueden importar solo desde shared y al shared le aplico la regla de que puede importar de cualquier otro. Es la solución que yo aplico que seguro no será la mejor pero la idea viene de las propias implementaciones de los monorepos. Igual @CodelyTv crea otro plugin para esto 😉

Por si te pudiera ayudar, yo lo he aplicado en front igual, la infraestructura tiene la misma razón de ser, solicitar y persistir datos pero en vez de a una BD puede ser a una api o memoria o lo que tu necesitas.

@@kodenix Entiendo y en cuanto a por ejemplo components/pages/hooks/contexts etc entraria en la carpeta de cada uno o en un directorio nuevo llamado por ejemplo ui

@@initiald2297 Todos los elementos que comentas forman parte de tecnología especifica de la capa de boundary,presentacion o como quieran verlo segun que arquitectura. En cualquier caso podrías crear un directorio "presentation" y meter ahí todo lo que interactúa con el usuario. ¿Por que no UI?, porque si fueces otro tipo de aplicación, ejemplo una API no le llamarías vistas a los controladores que manejan las peticiones HTTP o lo que sea que realiza un actor ->"otra aplicacion" (pero en el fondo son las vistas que ataca el cliente), por lo tanto podrias llamarle presentation o boundary, como quieras. pienso que mas importante es entender que pongas el nombre que ponga sepas que responsabilidades cumplen los elementos que se encuentran en cada capa.

Olvidé comentar que en el caso de un framework ya sea backend o frontend, ya traen una estructura de proyecto pero eso no quita que todos los elementos que crees una organizacion de tus capas dentro de la carpeta de codigo de tu framework, un ejemplo que vale para Angular y Nest es crear la estructura de carpetas presentation, infrastructure, domain, application dentro de src y mover los componentes, modulos, servicios, controladores por defecto que tare el framework a presentation. De esta forma aprovechas el esquema de herramientas del framework y tienes tu lógica aislada de tecnología

Si

Acoplarse a un framework es en síntesis lo mismo que acoplarse a una base de datos. Ambas pertenecen a la capa de infra

En realidad el orm que te brinda el framework permite cambiar de base de datos, podrias hacer tu app sin depender de un framework e integrando el orm que vos quieras manualmente a tu proyecto

bit.ly/linting-js 🙂

Otro aspecto que sería bueno tratar es que habeis tenido que dar demasiadas explicaciones para establecer el patrón, es decir, no hay ·Convention" y si mucha "Configuration". Just think about this. Usualmente las soluciones buenas son evidentes, obvias, y no requieren de tantos artefactos para arraigar.

@CodelyTv Por favor tenerlo en cuenta, con ejemplos practicos y sencillos se entiende mejor el tema

En un repositorio vos podés escribir y leer data. En "backend" haces implementaciónes de bases de datos. Por ejemplo MYSQL, Firestore. Para "frontend" también podes hacer algo similar pero con localstorage, o alguna API que por detrás consulte a la DB.

Sr.@@jefjef418 Excelente aporte

Claro tu aplicacion esta acoplada al framework, si quisieras migrarla a otro framework tendrias que reescribir todo devuelta

Dani Mono 🙂

@@CodelyTV gracias

Hexagonal está bien para sacar lo del dominio y de la capa de aplicación y poco más. Lo que tengas acoplado a la infraestructura, ahí se queda.

Es la que viene por defecto en IntelliJ 🙌

Leyendo un poco más entendí que el Dominio no se conecta directamente a Infraestructura si no que usa un puerto o interfaz que se conecta a un adapter y en la infraestructura es donde se hace la implementación.

Correcto! Clean Architecture es un tipo de arquitecturas, entre las que se encuentra la hexagonal 😊

Muchas gracias por tu mensaje!!

Ufff ETL...difícil de explicar bien, porque en los casos ejemplo (una tabla maestra y un par de tablas anidadas) es muy sencillo, escalable y flexible... pero cuando llegas a casos reales, las cosas son más complicadas y aunque en esencia es lo mismo, el código se complica para manejar casos especiales y esos casos son diferentes según el problema que tengas... Es decir, si tomas como ejemplo un caso complicado, la solución está muy ligada a ese problema y es probable que no la puedas usar siempre... por eso digo que ETL es muy difícil de explicar bien.

Trabajé en un proyecto ETL donde la tabla maestra dependía no sólo de otras tablas, sino de otros sistemas como SAP , apps privadas, archivos, datos en memoria... y no era una única tabla maestra, era un modelo completo de al menos 100 tablas... Ahí aprendí por las malas que una solucion general para ETL no existe, siempre hay casos especiales que "dañan" el modelo general (lo que aprendes en un curso), y esos casos no sólo están influenciados por la complejidad técnica, sino también por lo que el cliente quiere, y si haces una app que va a ser usada por diferentes clientes y cada uno quiere importar cosas diferentes, con archivos y formatos diferentes, y filtrar/transformar los datos de manera diferente, todo se convierte en un desafío de la ingeniería... y manejar eso en un video/clase/curso es imposible... Y la verdad es que se aprende más con la experiencia que con un curso ;) claro, los estudios son necesarios para tener más herramientas a la hora de solucionar problemas de verdad difíciles

Un ejemplo básico y fácil de ETL es como Elasticsearch extrae datos de una BD (MySql, MSSQL...), los transforma en Json y los indexa en su base de datos... Todo funciona a pedir de boca, defines los scripts de extracción, simples selects, y como esos "Records" se transforman en Json, y donde esos Json son guardados en Elasticsearch... simple Pero tuve proyectos donde eso no sirvió porque los datos de la BD no eran suficientes, había que enriquecerlos con sistemas remotos, cosas en las que la gente de Elasticsearch no pensó, ni programó... el caso general (los simples scripts) no sirve y hay que escribirse un ETL completo desde cero para ese cliente...

en esos casos hay que inventarse una estructura básica y genérica que es la que trabaja los datos al final... digamos XML... tu algoritmo consume los datos desde ese XML definido por ti y haces con ellos lo que quieras... si hay un cliente con lógica especial, entonces escribes un programa que toma esos datos de entrada en el formato que sea y los transforma en TU XML... esa es la forma más elegante de mantener tu código limpio... no tiene buen performance porque los datos tienen que ser transformados hacia XML, y de XML hacia tu modelo, pero es demasiado flexible Si lo haces bien, puedes tener un único algoritmo que importa datos en tu DB y puedes cambiar la fuente de datos on-the-fly... puedes importar datos de SAP, y con el mismo algoritmo puedes cambiar a importarlos desde un archivo, o tu misma BD Échale un ojo a Mirth

A mi también me interesa verlo aplicado a ETL ya que la mayoría de ejemplos de arquitectura se basan en aplicaciones transaccionales

Eso es lo que nunca dicen, porque este tipo de "arquitecturas" o "patrones de diseño" no existen más que en un mundo ideal, sólo sirven para resolver problemas de aprendizaje, en el mundo real la arquitectura se debe de adaptar al proyecto, no al revés.

Totalmente 😂

Yeah!!, y que Clean y que la futura nueva arquitectura. Si miras con perspectiva de principios de diseño a todas las arquitecturas por capas, verás los principios de alta cohesión, bajo acoplamiento, de dependencias y abstracciones estables, etc, etc, etc.

Exactamente, todo en español 🙂

@@CodelyTV y en qué lenguaje explican el de patrones de diseño ?

Semana que viene verás cositas de ello 😬

@@CodelyTV Que ganas tengo