Basado en la decisión del Stack tecnológico y la Decisión de Arquitectura, se opta por una estrategia Multi-Repo para el proyecto, separando el backend (Spring Boot/Java) del frontend (Android/Kotlin).

<aside> <img src="notion://custom_emoji/443556c2-6f69-81c8-8433-0003f0fd2e9f/298556c2-6f69-803a-9224-007a760931b0" alt="notion://custom_emoji/443556c2-6f69-81c8-8433-0003f0fd2e9f/298556c2-6f69-803a-9224-007a760931b0" width="40px" />

Repositorio Frontend

</aside>

<aside> <img src="notion://custom_emoji/443556c2-6f69-81c8-8433-0003f0fd2e9f/298556c2-6f69-80dc-97e9-007a6307c98a" alt="notion://custom_emoji/443556c2-6f69-81c8-8433-0003f0fd2e9f/298556c2-6f69-80dc-97e9-007a6307c98a" width="40px" />

Repositorio Backend

</aside>

🏗️ Justificación Técnica

1. Arquitectura Hexagonal + DDD

• Separación de responsabilidades: La arquitectura hexagonal requiere límites claros entre el dominio y la infraestructura
• Puertos y Adaptadores: Cada repositorio puede implementar sus propios adaptadores sin contaminar el dominio del otro
• Testabilidad independiente: Permite testing aislado del backend y frontend por separado

2. Stack Tecnológico Diferenciado

3. Flujo de Trabajo del Equipo (8 desarrolladores)

• Desarrollo paralelo: Backend y frontend pueden evolucionar independientemente
• Reducción de conflictos: Menos probabilidad de conflictos de merge entre tecnologías diferentes
• Especialización: Permite que desarrolladores se enfoquen en su área de expertise

📊 Análisis Comparativo

Multi-Repo vs Monorepo