2026En desarrolloProyecto independiente

Plataforma Integral de Gestión Crediticia

Cubrir el ciclo crediticio completo, de la admisión y la evaluación hasta los créditos y el seguimiento de cartera, sobre una base modular que crece por fases.

Rol: Desarrollo full stack
Tecnologías: Laravel · PHP · React · MySQL · Monolito modular

Dominios de negocio modulares: 9
Tests que vigilan las fronteras entre módulos: 110
Niveles de acceso: usuario, rol y sede: 3

Contexto operativo

Nueve dominios de negocio con reglas propias, evaluación diferenciada por tipo de cliente y accesos delimitados por usuario, rol y sede.

Solución construida

Monolito modular: cada dominio es un módulo con sus propias capas, que se completan módulo a módulo, y cada dependencia entre módulos queda declarada en un test.

Arquitectura del sistema

El flujo muestra cómo se separan las responsabilidades desde la entrada HTTP hasta la persistencia. En amarillo, la capa que concentra las reglas del negocio.

Arquitectura4 capas

La capa Domain no conoce HTTP, base de datos, Auth ni Eloquent. Entre módulos, la vía de entrada es la capa Application de cada uno, con sus Queries, Actions y DTOs públicos; las excepciones, como el usuario autenticado, están acotadas por tests.

Depende de Application

Valida la entrada con requests y delega en un caso de uso, sin persistir datos ni resolver servicios a mano.

Depende de Domain, Infrastructure

Coordina cada caso de uso y persiste a través de Infrastructure. Es la vía de entrada para otros módulos, con sus Queries, Actions y DTOs públicos.

No depende de ninguna capa

Sin HTTP, DB, Auth ni Eloquent: las demás capas dependen de ella, nunca al revés.

Depende de Domain

Eloquent, consultas optimizadas y adapters. Conoce el dominio; el dominio no la conoce a ella.

Evidencia verificable

Las 152 rutas de la API congeladas en un test de contrato que fija método, URI, controlador y middleware de cada una.
110 tests de arquitectura: los módulos del flujo crediticio no forman ciclos ni importan la infraestructura de otro módulo, ninguna consulta cruda toca tablas ajenas, y toda dependencia nueva entre módulos tiene que declararse.
Autorización en tres niveles: sesión JWT, permiso granular por acción y alcance por sede.
Capa Domain sin HTTP, DB, Auth ni Eloquent; la capa Http no persiste datos ni resuelve servicios a mano.

Del repositorioExtracto del test de contrato

// RouteContractTest.php['GET', 'api/v1/proceso-negocio',  ProcesoNegocioController@index,  ['jwt', 'permiso:proceso.listar']],['PATCH', 'api/v1/proceso-negocio/{id}',  ProcesoNegocioController@update,  ['jwt', 'permiso:proceso.editar']],

Cada fila fija método, URI, controlador y middleware. Si una migración los cambia, el test falla antes que el frontend.

Del repositorioExtracto de los tests de arquitectura

// ModuleDependencyBoundaryTest.phptest_credit_flow_module_dependency_graph_is_acyclictest_cross_module_dependency_inventory_stays_fixed// ControllerHttpBoundaryTest.phptest_http_layer_does_not_execute_unallowlisted_persistence_operationstest_http_layer_does_not_use_the_service_locator// TableOwnershipBoundaryTest.phptest_ninguna_consulta_cruda_toca_una_tabla_de_otro_ownertest_la_lista_de_excepciones_sigue_vacia

Las fronteras entre módulos no dependen de la disciplina: 110 tests fallan si aparece una dependencia no declarada entre módulos o si una consulta cruda toca tablas ajenas.

Resultado

El valor del proyecto está en convertir reglas operativas dispersas en un sistema trazable, probado y mantenible.

¿Necesitas resolver un proceso similar?

Conversemos sobre el flujo, las reglas y la arquitectura que necesita tu sistema.

Contáctame