Repository navigation
Entrega #1
- 1. Justificación de la estructura de carpetas
- 2. Diagrama de secuencias funcionalidad compleja
- 3. Preparación para APIGateway
La estructura del proyecto se eligió de esta manera buscando separar las responsabilidades de la aplicación en diferentes capas. La carpeta api concentra la exposición de los servicios mediante Django REST Framework, incluyendo serializers, views, urls y manejo de errores. De esta manera, la lógica relacionada con HTTP y la comunicación con el cliente queda separada de la lógica propia del negocio.
La carpeta domain contiene los elementos relacionados directamente con el dominio del negocio, como los builders, las abstracciones definidas mediante ports, las excepciones y otros componentes que representan reglas o comportamientos que no deberían depender directamente de Django o de una tecnología externa. Esto facilita aplicar principios SOLID, especialmente el principio de inversión de dependencias, ya que el dominio puede depender de abstracciones en lugar de implementaciones concretas.
Por otra parte, infra contiene las implementaciones concretas que permiten que el sistema se comunique con elementos externos, como los servicios de validación, pasarelas de pago, notificadores y las implementaciones de los Factory Methods. Esta separación permite reemplazar una implementación sin modificar la lógica principal del negocio.
Finalmente, las estructuras propias de Django (models.py, views.py, serializers.py, forms.py, etc.) permiten mantener la compatibilidad con el framework y facilitar su funcionamiento actual como monolito. En conjunto, esta organización busca que las dependencias estén dirigidas hacia componentes más estables y que las responsabilidades estén separadas.
La principal razón para utilizar esta estructura pensando en una futura migración mediante Strangler Pattern es que permite establecer límites dentro del monolito desde el comienzo. En lugar de tener toda la lógica distribuida y acoplada entre las vistas, modelos y servicios de Django, se busca que las funcionalidades estén separadas entre API, dominio e infraestructura.
El sistema está preparado para una futura incorporación de un API Gateway porque actualmente centraliza la comunicación con el cliente mediante una capa de API construida con DRF, CBV, serializadores y rutas independientes de la lógica de negocio. Esto permite que, en una evolución hacia una arquitectura distribuida, el Gateway pueda convertirse en el punto único de entrada, encargándose de funciones como autenticación, enrutamiento y control de acceso, mientras dirige cada solicitud al servicio correspondiente. Además, la separación entre API, dominio e infraestructura facilita aplicar posteriormente el Strangler Pattern, permitiendo extraer funcionalidades del monolito progresivamente sin modificar directamente al cliente.