How alonsolmz/algyestdatos-proyectocompleto works
1. This repository is split into two independently run applications: a Java/Spring backend in backend/ and an Astro-based frontend in frontend/. The backend provides the domain logic and persistence; the frontend provides the user interface.
2. The backend is a Spring Boot application (Grupo02Application.java) built with Maven. Its package layout follows a standard layered architecture: controller → service → repository → model, with DTO and mapper layers in between.
3. The core domain is inventory/order management. The main entities are Almacen, Cliente, Producto, Ubicacion, Pedido, DetallePedido, and MovimientoStock. These represent warehouses, customers, products, locations, orders, order lines, and stock movements.
4. REST endpoints are organized by domain area through separate controllers for each entity. These controllers are the HTTP boundary of the system and are responsible for exposing CRUD-style operations and delegating work to services.
5. Business logic is concentrated in the service layer, with concrete implementations under service/impl. This layer is where validations, orchestration, and domain-specific operations belong, rather than in controllers or repositories.
6. Persistence is handled through one repository interface per aggregate/entity in repository/. The presence of data.sql in src/main/resources indicates the backend starts with seed data, so the application likely supports preloaded sample records for development/demo use.
7. The API does not expose JPA entities directly. Instead, the project uses DTOs (dto/) and mapper classes (dto/mapper/) to convert between API payloads and internal model objects. This is an important boundary for the architecture diagram because it separates transport concerns from persistence/domain concerns.
8. There is a custom data-structures package under structure/ containing ListaPedidos, NodoPedido, and OperacionesLista. This is notable for an algorithms/data-structures project: orders are not only persisted in the database, but there is also an in-memory custom list structure used for specific order operations or demonstrations.
9. The frontend is an Astro application with a small component/layout/page structure. It has a dashboard layout, a product form component, a home page, and a RegistroProducto page, which suggests the UI is focused on product registration and a lightweight dashboard experience.
10. The frontend and backend are separated at the repository level and communicate over HTTP rather than sharing code. In the architecture diagram, treat the frontend as a client consuming the backend’s REST API.
11. Testing exists on the backend side, including application tests and service tests for ProductoServiceImpl. That indicates the service layer is an important test boundary and likely the most business-critical part of the backend.
12. Operationally, the backend is meant to be run from the Maven wrapper/IDE, while the frontend is run with npm run dev. The project therefore has two runtimes: Java for API/business logic and Node/Astro for the presentation layer.
Main entry points: src Astro app · controller REST controllers · impl Service impls · repository Repositories
Components 15
Backend
Spring Boot API, domain logic, persistence, and custom data structures.
- Spring Boot app · Application entrypoint and overall backend bootstrap.
backend/src/main/java/pe/edu/pe/Grupo02/Grupo02Application.java - REST controllers · HTTP boundary exposing CRUD-style endpoints for each domain area.
backend/src/main/java/pe/edu/pe/Grupo02/controller - Service layer · Interfaces defining orchestration and domain operations.
backend/src/main/java/pe/edu/pe/Grupo02/service - Service impls · Concrete validation, coordination, and use-case implementation.
backend/src/main/java/pe/edu/pe/Grupo02/service/impl - Repositories · Repository interfaces for database access per aggregate/entity.
backend/src/main/java/pe/edu/pe/Grupo02/repository - Domain models · Core inventory and order entities used internally and persisted.
backend/src/main/java/pe/edu/pe/Grupo02/model - DTOs · API payload models separating transport from domain entities.
backend/src/main/java/pe/edu/pe/Grupo02/dto - Mappers · Converts between DTOs and domain/model objects.
backend/src/main/java/pe/edu/pe/Grupo02/dto/mapper - Order list · In-memory custom list structure for order-related operations.
backend/src/main/java/pe/edu/pe/Grupo02/structure - Seed data · Initial sample records loaded at startup for development/demo use.
backend/src/main/resources/data.sql - Backend tests · Application and service tests, especially around Producto services.
backend/src/test/java/pe/edu/pe/Grupo02
Frontend
Astro UI consumed over HTTP by the backend API.
- Astro app · Frontend application runtime and build entrypoint.
frontend/src - Dashboard layout · Shared layout framing the frontend experience.
frontend/src/layouts/DashboardLayout.astro - Product form · Reusable form component centered on product registration.
frontend/src/components/FormularioProducto.astro - Pages · Public routes for home and product registration screens.
frontend/src/pages
Connections 16
- Spring Boot app → REST controllers: starts HTTP API · Bootstraps controllers as the REST entrypoint.
- REST controllers → Service layer: delegates · Controllers pass requests to service interfaces.
- Service layer → Service impls: implemented by · Service contracts are fulfilled by concrete implementations.
- Service impls → Repositories: reads/writes · Business logic persists and loads data through repositories.
- Repositories → Domain models: maps entities · Repositories operate on the domain model layer.
- REST controllers → DTOs: accepts/returns · API contracts are defined with DTOs rather than entities.
- DTOs → Mappers: translated by · DTOs are converted to and from internal model objects.
- Mappers → Domain models: maps to model · Mappers connect transport objects to domain entities.
- Service impls → Order list: uses · Order workflows also use a custom in-memory list structure.
- Seed data → Repositories: preloads · Seed data initializes repository-backed sample records.
- Backend tests → Service impls: verifies · Service tests focus on business rules and orchestration.
- Astro app → Dashboard layout: composes · The Astro app uses a shared dashboard shell.
- Astro app → Product form: renders · Pages compose reusable UI components.
- Astro app → Pages: routes · Route-level pages define the user-facing screens.
- Pages → Product form: uses · Pages reuse the product form component.
- Astro app → REST controllers: calls API · Frontend consumes the backend over HTTP.