Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/BladimirGS/judicial-backend/llms.txt

Use this file to discover all available pages before exploring further.

Judicial Backend is built as a modular monolith — a single deployable Express/TypeScript application whose business logic is partitioned into four independent domain modules (apelacion, busqueda, estadistica, auth), each fully self-contained. Modules share no direct imports between them; instead, they communicate exclusively through HTTP and through cross-cutting infrastructure layers that are explicitly separated from domain concerns.

​
Four Domain Modules, One Deployment

The system hosts four modules registered on a central router at /api:
Mount pathModuleAccess
/authauthPublic
/apelacionesapelacionJWT-protected
/busquedasbusquedaJWT-protected
/estadisticasestadisticaJWT-protected
Each protected route passes through the protect middleware (RS256 JWT verification via JWKS) before any module controller is reached. Rate limiting is also applied at this level — authLimiter for auth routes and apiLimiter for business routes. 
// src/routes/index.ts
router.use('/auth', authLimiter, authRoutes);
router.use('/apelaciones', apiLimiter, protect, apelacionRoutes);
router.use('/busquedas', apiLimiter, protect, BusquedaRoutes);
router.use('/estadisticas', apiLimiter, protect, estadisticaRoutes);

​
Five Layers Within Every Module

Every domain module enforces the same internal layering. Each layer has a single, non-overlapping responsibility:
LayerTypical filesResponsibility
Interface*.routes.ts, *.controller.tsParse HTTP request, call the service, return a typed response via responseUtil
Application*.service.tsOrchestrate repositories, mappers, and reports; enforce business rules
Transformation*.mapper.tsConvert TypeORM entities into response DTOs; never touch HTTP or database details
Infrastructure*.repository.ts, *.sp-repository.tsAll data access — ORM QueryBuilder queries or raw stored-procedure calls
Domain*.type.ts, *.dto.tsPure TypeScript interfaces and class-validator DTOs; no imports from the project

​
Cross-Cutting Infrastructure

Four top-level directories sit outside all modules and are consumed by any module that needs them:
DirectoryPurpose
core/AppError, asyncHandler, globalErrorHandler, validation.middleware, pagination utilities, and responseUtil
shared/Document-generation tools (shared/pdf, shared/excel), base mappers (shared/mappers), and base types (shared/types)
database/21 TypeORM entities and four shared repositories (ORM catalog lookups + stored-procedure wrappers)
config/TypeORM DataSource (MSSQL), validated environment variables, and the Pino logger

​
Dependency Rules

The architecture enforces a strict one-directional dependency graph. Violating these rules breaks the encapsulation model:
  • Controllers may only import their module’s service and core/utils/response.util.
  • Services may only import repositories (module-level or shared), mappers, and report builders.
  • Module repositories may only import entities from database/entities/.
  • SP repositories (database/repositories/*.sp-repository.ts) may only import their local types and core/errors/app-error.
  • Report builders (*.report.ts) may only import from shared/pdf or shared/excel.
  • DTOs are pure interfaces — they import nothing from the project.
  • No module may import directly from another module.

​
Module Dependency Diagram

The following diagram (from ARQUITECTURA.md §9) shows the full request path from HTTP entry-point to database and back: 
HTTP Request
│
▼
[Routes] ─────────────────────────────────────────────────────────────────┐
│  [auth/auth.routes → AuthController]  (public)                          │
│                                                                          │
│  [apelaciones / busquedas / estadisticas]                                │
│      │                                                                   │
│      ▼                                                                   │
│  [protect middleware]  (JWT verify via JWKS)                             │
│      │                                                                   │
│      ▼                                                                   │
│  [Controller]  ←──  [validation.middleware]                              │
│      │                                                                   │
│      ▼                                                                   │
│  [Service]                                                               │
│      │                                                                   │
│      ├──► [Module Repository] ──────────────► [TypeORM / MSSQL]         │
│      │                                                                   │
│      ├──► [database/repositories/] ─────────► [MSSQL Stored Procedures] │
│      │     (SP + Catalog ORM)                                            │
│      │                                                                   │
│      ├──► [Mapper] ──────────────────────────► DTO de respuesta          │
│      │                                                                   │
│      └──► [Report] ──────────────────────────► shared/pdf · shared/excel │
│                │                                                         │
│                └──► fonts/  (PdfPrinter)                                 │
│                                                                          │
└──────────────────── shared/mappers/ · shared/types/ ────────────────────┘
Services are constructed using functional factory functions rather than classes, enabling dependency injection and isolated unit testing without a DI container. Every service factory receives its repositories as arguments, so test suites can substitute mock repositories at construction time.
export const createApelacionService = (
    catalogoRepo,
    asignacionRepo,
    folioRepo,
    apelacionRepo,
    getManagerFn = getManager, // optional; defaults to the live DataSource manager
) => ({
    // service methods …
});

​
Standardized HTTP Responses

All controllers use responseUtil from core/utils/response.util.ts to produce consistent JSON shapes. The helper covers the full lifecycle of an API response: 
responseUtil.success(res, data);           // 200 { status, message, data }
responseUtil.created(res, data);           // 201 { status, message, data }
responseUtil.notFound(res, message);       // 404 { status, code, message }
responseUtil.badRequest(res, message);     // 400 { status, code, message }
responseUtil.validationError(res, errors); // 400 { status, code, message, errors }
responseUtil.file(res, buffer, type, filename); // 200 binary stream
responseUtil.error(res, message, code);    // 5xx { status, code, message }
Errors thrown as AppError instances (with statusCode, code, and optional details) are caught by globalErrorHandler and serialized through the same shape, keeping client error handling uniform across every endpoint.

​
Explore Further

Module Reference

Deep-dive into each of the four domain modules — their purpose, layer breakdown, routes, and service methods.

Database Layer

TypeORM entity catalog, shared repositories, and the stored procedures that back the data access layer.

Build docs developers (and LLMs) love

Get started for freeTalk to us