pablocizq/laboratorioingweb

1. Overall shape

This repository is a two-process backend: a gateway service at the edge and an app-server that owns the core business logic. The code is organized around a layered architecture on the app-server side, with a thin API/auth layer in the gateway and an internal message/RPC-based integration between them.

2. Gateway as the public entrypoint

backend/gateway exposes the external HTTP API. Its responsibilities are routing, request validation, authentication, and translating HTTP calls into internal RPC requests. It does not appear to own business rules or persistence; instead it forwards work to the app-server.

3. App-server as the domain owner

backend/app-server contains the core booking system. It implements use cases such as creating reservations, consulting reservations, login, listing spaces, and modifying spaces. This service also owns database access and the server-side message consumer that answers RPC calls from the gateway.

4. Layered internal structure in app-server

The app-server is split into:

• application: use-case modules like crear-reserva, cancelar-reserva, iniciar-sesion, obtener-espacios

• domain: entities, value objects, policies, domain services, and domain errors

• infrastructure: SQL repositories, database bootstrapping/seeders, and messaging plumbing

This indicates a classic dependency direction: use cases depend on domain abstractions, while infrastructure provides concrete implementations.

5. Domain model and business boundaries

The domain centers on three main entities: Usuario, Espacio, and Reserva. Supporting types include CategoriaEspacio and IntervaloReserva, plus a conflict detector (DetectorConflictosHorario) and a permissions policy (PoliticaPermisosReserva). Those pieces suggest the main business constraints are reservation eligibility, time-window validation, and conflict checking.

6. Persistence boundary

App-server defines repository interfaces in domain/repositories and SQL implementations in infrastructure/repositories. Concrete classes like RepositorioEspaciosSQL, RepositorioReservasSQL, and RepositorioUsuariosSQL imply the system persists to a relational database. The infrastructure/database folder and seeders show the DB can be initialized with sample spaces, users, and past reservations.

7. Messaging boundary and internal RPC

Both services include a messaging folder with broker connection code, and the app-server has rpc-server.js while the gateway has rpc-client.js. That means the gateway likely sends RPC-style requests over a broker (commonly RabbitMQ, though the repo name alone doesn’t confirm the broker type), and the app-server acts as the responder. This is the key integration boundary between HTTP ingress and domain execution.

8. HTTP/API surface in the gateway

The gateway is organized by feature area with auth, espacios, and reservas controllers and routes. The routes are guarded by middleware such as autenticar and validar-payload, so authentication and request-shape validation happen before the request is translated into internal service calls.

9. Authentication and token flow

gateway/src/services/token.service.js and config/jwt.config.js indicate JWT-based auth. The auth.controller.js and iniciar-sesion use case together suggest the login flow is handled through the gateway API, with token issuance/verification at the edge before protected reservation endpoints are allowed through.

10. Data flow for a typical request

A client request enters the gateway via HTTP, passes middleware validation/authentication, is mapped by a controller to an RPC call, and is sent through the broker to the app-server. The app-server’s RPC server invokes the relevant application use case, which enforces domain rules and calls a repository. The result returns back through RPC to the gateway and then to the client.

11. Reservation-specific business flow

Reservation creation likely follows a stricter path than simple reads: validate payload in gateway, execute crear-reserva in app-server, check policy and schedule conflicts through domain services, then persist the reservation via the SQL repository. The presence of “consultar reservas vivas”, “mis reservas”, and “cancelar reserva” suggests separate read/write use cases rather than a generic CRUD model.

12. Deployment and runtime

Both services have their own package.json and Dockerfile, and there is a top-level backend/docker-compose.yml. That points to containerized deployment with at least the gateway, app-server, and a message broker/database stack coordinated by Compose. The main runtime is Node.js.

13. What to show in an architecture diagram

A good diagram should emphasize these boundaries:

• external clients calling the gateway

• the gateway handling JWT auth, validation, and routing

• the broker/RPC channel between gateway and app-server

• the app-server’s split into application/domain/infrastructure

• the SQL database behind repository implementations

• the seeders as initialization data, not runtime logic

14. Notable design characteristic

This is not a monolithic Express app. It’s a deliberately separated backend where the gateway is a thin edge layer and the app-server is the system of record for business rules and persistence. The strongest architectural signal is the combination of DDD-style layering inside app-server and messaging-based service boundary between gateway and core logic.