najhelybs/vacunacioncard

1. Overall shape

- This is a Java Spring Boot / Maven application for a digital vaccination card system.

- The code is organized as a classic layered architecture: domain models, repositories, services, and a very thin or not-yet-populated controller/config layer.

2. Entry point and runtime

- VacunacioncardApplication is the Spring Boot bootstrap class.

- Build and execution are managed with Maven Wrapper (mvnw, .mvn/) and configuration lives in src/main/resources/application.properties.

3. Core architectural boundary

- The most important boundary is between:

- model/: business entities and value objects

- repository/: persistence access

- service/: business rules and orchestration

- The repository tree strongly suggests Spring Data-style repositories, with services depending on repository interfaces rather than concrete storage details.

4. Domain subsystems

- The model layer is split into business domains:

- auth: CuentaUsuario, Rol, Permiso, SesionUsuario

- usuario: Usuario, Paciente, Enfermero, Administrador, SeguroMedico

- vacunacion: CartillaVacunacion, EsquemaVacunacion, Vacuna, RegistroVacuna, Laboratorio, UbicacionAplicacion

- cita: CitaVacunacion, Horario, DiaSemana

- campania: CampaniaVacunacion, CentroVacunacion

- salud: Alergia, CondicionMedica, Contraindicacion

- notificacion: Notificacion, NotificacionRecordatorio, NotificacionSistema

- comun: shared concepts such as Calendario, Contacto, Direccion, RegistroAuditoria

5. Business service layer

- Each domain has its own service interface and implementation package.

- This layer contains the application rules for:

- user/auth management

- vaccination card and vaccine records

- appointments and schedules

- vaccination campaigns and centers

- health restrictions and contraindications

- notifications

- auditing and calendar logic

- The pattern here is clear: interfaces define contracts, impl classes implement behavior.

6. Repository layer and persistence responsibility

- Repositories exist for each major aggregate/domain, such as PacienteRepository, CitaVacunacionRepository, VacunaRepository, NotificacionRepository, and others.

- This layer isolates persistence concerns from business logic and acts as the data access boundary for the services.

- There is no separate DAO layer; repositories are the persistence abstraction.

7. Notification subsystem

- Notification handling is a distinct subsystem:

- domain types distinguish system notifications from reminder notifications

- NotificacionServiceImpl orchestrates notification behavior

- INotificacionFactory plus concrete factories (RecordatorioNotificacionFactory, SistemaNotificacionFactory) implement Factory Method

- This subsystem likely creates the right notification type depending on the event or use case.

8. Shared cross-cutting concerns

- RegistroAuditoria and its service/repository provide an audit trail for system actions.

- Calendario and related services provide shared date/scheduling functionality reused by appointments and campaigns.

- ServiceException is the explicit application-level error type, indicating service-layer validation or business-rule failures.

9. Design patterns used intentionally

- The repository is a course project on design patterns, and the structure reflects that:

- Factory Method in the notification creation flow

- Singleton in ConfiguracionSistema

- These patterns are not just incidental; they are modeled as first-class parts of the service layer.

10. Data flow through the system

- The usual request path is:

- an upper layer would call a service

- the service applies business rules and coordinates domain objects

- the service delegates persistence to a repository

- domain objects such as patients, vaccines, appointments, or notifications are returned/updated

- Because controllers are not present in the tree, the top-most presentation boundary is currently absent or unfinished.

11. Testing and verification

- The test tree focuses on:

- the main application bootstrap

- notification model behavior

- notification factory behavior

- singleton configuration

- selected service implementations such as session, notification, and patient services

- This shows the project verifies both business logic and pattern behavior, not just persistence wiring.

12. What to diagram

- A good architecture diagram should center on:

- the Spring Boot application

- the service layer as the orchestration hub

- the repository layer as persistence boundary

- the major domain clusters: auth, usuario, vacunacion, cita, campania, salud, notificacion, comun

- the pattern subcomponents for notifications and system configuration