Skip to content

Estructura del Proyecto

Un proyecto es la suma de mucho esfuerzo, donde las pequeñas tareas cuentan; cumplir con el plazo designado, requerimientos y hacerlo lo más optimo posible, es sin lugar a duda complicado de conseguir.

Por lo tanto, debemos facilitarnos las cosas pensando en el futuro y no solo en cómo cumplir con la tarea a corto plazo. Por esta razón, lo mejor es escribir el código pensando en que sea sencillo de entender para humanos, una celebre frase que ejemplifica esto es la siguiente:

El primer punto a considerar, es pensar en el paso a producción y por tanto asegurarnos de tener una estructura lo suficientemente robusta, que sea sencilla de entender y a su vez sumamente flexible; para lograr esto, se debe saber modularizar cada parte del sistema y hacerlo de manera consistente en cada sitio del desarrollo. En este sentido, la forma conseguida es:

Generalidades

El proyecto se construyo usando el enfoque de Monolito Modular, el cual se diferencia de los monolitos tradicionales, debido a que hace enfasis en la clara división de responsabilidades de cada componente del sistema.

Backend

Se optó por implementar Arquitectura Hexagonal en esta parte del sistema, ya que aporta la tan ahnelada flexibilidad que debe tener todo buen sistema, aunque como todo se debe tener precaución en la cantidad presente, sino se cae en el completo caos.

Sin embargo, la manera tradicional de implementarla no es la elegida, pues conlleva lo siguiente:

  1. Crear tres carpetas enormes que hacen un martirio buscar un fichero específico.
  2. Falta de modularidad y flexibilidad.
  3. Hace que sea complejo entender cada componente.
  4. Pone muy complicado el trabajo en equipo.
  5. Es dificil de mantener y escalar.

Para solventar esto, aplicamos la arquitectura hexagonal con una variante, la cual consiste en aplicar vertical slicing (se divide la capa en múltiples componentes verticales), en comparación con la forma tradicional; se aplican las tres capas, pero a nivel de cada entidad.

Los directorios más relevantes son:

  • db/*: Dentro de este directorio se incluye todo el código ligado a la persistencia de datos. No importa si es en local o en remoto.
  • routes/*: Contiene todos los puntos de entrada al backend.

Ejemplo de la estructura de carpetas:

  • Directorydb
    • Directorymigrations/
    • Directorysqlite/
  • Directorysrc
    • Directoryauth
      • Directoryapp/
      • Directorydom/
      • Directoryinfra/
      • Directorytest/
    • Directoryorder-management
      • Directoryapp/
      • Directorydom/
      • Directoryinfra/
      • Directorytest/
    • Directoryproduct-management
      • Directoryapp/
      • Directorydom/
      • Directoryinfra/
      • Directorytest/
    • Directoryreport-management
      • Directoryapp/
      • Directorydom/
      • Directoryinfra/
      • Directorytest/
    • Directoryroutes/ sumamente importante
    • Directoryshared/
      • Directoryapp/
      • Directorydom/
    • Directoryuser-management
      • Directoryapp/
      • Directorydom/
      • Directoryinfra/
      • Directorytest/

Con respecto al frontend, se decidió seguir un enfoque más “libre” por así decirlo. En versiones posteriores se buscará documentar esta area del sistema. Además, se aplicaron algunos patrones de diseño y la mayoría de principios Solid. Esto se ve en la guía de inicio backend.