Estructura del Proyecto App-Profuturo
Estructura recomendada
app-motor/
└── app/
├── src/main/
│ ├── java/mx/profuturo/appmotor/
│ │ ├── core/
│ │ │ ├── common/
│ │ │ ├── extensions/
│ │ │ ├── utils/
│ │ │ ├── validation/
│ │ │ ├── exceptions/
│ │ │ ├── logger/
│ │ │ └── session/
│ │ │
│ │ ├── data/
│ │ │ ├── remote/
│ │ │ │ ├── api/
│ │ │ │ ├── dto/
│ │ │ │ ├── datasource/
│ │ │ │ └── interceptor/
│ │ │ ├── local/
│ │ │ │ ├── db/
│ │ │ │ ├── datastore/
│ │ │ │ └── cache/
│ │ │ ├── mapper/
│ │ │ └── repository/
│ │ │
│ │ ├── domain/
│ │ │ ├── model/
│ │ │ ├── repository/
│ │ │ └── usecase/
│ │ │
│ │ ├── presentation/
│ │ │ ├── activity/
│ │ │ ├── navigation/
│ │ │ ├── base/
│ │ │ ├── components/
│ │ │ └── features/
│ │ │ └── login/
│ │ │ ├── ui/
│ │ │ ├── viewmodel/
│ │ │ ├── adapter/
│ │ │ ├── state/
│ │ │ └── event/
│ │ │
│ │ │
│ │ │
│ │ ├── di/
│ │ │ ├── NetworkModule.kt
│ │ │ ├── RepositoryModule.kt
│ │ │ ├── UseCaseModule.kt
│ │ │ └── StorageModule.kt
│ │ │
│ │ └── MainActivity.kt
│ │
│ └── res/
│ ├── layout/
│ ├── navigation/
│ ├── drawable/
│ ├── values/
│ ├── menu/
│ └── mipmap/
│
└── build.gradle.kts
Explicación de carpetas
core/
Aquí vive todo lo que es gobal y reutilizable dentro del proyecto.
Ejemplos:
- validation/RfcValidator.kt
- utils/DateUtils.kt
- session/UserSession.kt
- logger/AppLogger.kt
data/
Implementa el acceso a datos remotos y locales.
Subcapas:
- remote/: APIs, servicios externos, interceptores
- local/: Room, DataStore, caché
- mapper/: transformación entre DTO, Entity y Domain Model
- repository/: implementación de repositorios
domain/
Capa totalmente del negocio.
Subcapas:
- model/: modelos del dominio
- repository/: contratos de repositorio
- usecase/: casos de uso
presentation/
Todo lo relacionado con la UI XML y navegación.
Subcapas:
- activity/: activity principal o auxiliares
- navigation/: nav graph, destinations, helpers
- base/: BaseFragment, BaseViewModel, estados comunes
- components/: componentes UI reutilizables internos
- features/: cada funcionalidad organizada por carpeta
Organización por features
Cada feature debe encapsular sus elementos propios.
Ejemplo:
presentation/
└── features/
├── login/
│ ├── LoginFragment.kt
│ ├── LoginViewModel.kt
│ ├── LoginUiState.kt
│ └── LoginUiEvent.kt
Manejo de estado
Se recomienda utilizar un enfoque basado en estados para la UI:
- UiState (Loading, Success, Error)
- UiEvent para acciones de usuario
Esto permite una UI más predecible y desacoplada.
Flujo de datos
El flujo de la aplicación sigue la siguiente dirección:
Presentation → Domain → Data
- La capa de Presentation consume casos de uso (UseCases)
- Domain contiene la lógica de negocio
- Data provee la información desde fuentes locales o remotas
Esto garantiza un bajo acoplamiento entre capas y facilita el mantenimiento del código.
XML recomendados
Layouts
fragment_login.xmlfragment_home.xmlitem_user.xmldialog_error.xml
Navigation
main_nav_graph.xml
Values
strings.xmlcolors.xmlthemes.xmldimens.xml
Regla clave
Aunque sea un solo proyecto, no se debe mezclar todo en cualquier paquete.
Conclusión
La estructura propuesta mantiene orden, claridad y escalabilidad, permitiendo trabajar dentro de un solo proyecto sin perder buenas prácticas de arquitectura. Facilita la organización del código, mejora la mantenibilidad y prepara la aplicación para crecer de forma controlada.