gym pass api

API de gimnasio 2.0

La API para la gestión del registro en los gimnasios, realizado en .NET 8 es una recreación de una antigua API realizada en Node.js. Es posible administrar gimnasios, cheques e información del usuario, abordando conceptos como CQRS, RBAC, DDD y príncipes sólidos.

Tecnologías utilizadas

• .NET 8
• ASP.NET
• XUnit (prueba unitaria)
• Núcleo de marco de entidad
• Swagger (documentación de API)

Conceptos usados

• Diseño impulsado por el dominio (DDD)
• Principios sólidos
• Control de acceso basado en roles (RBAC)
• Segregación de responsabilidad de consulta de comandos (CQRS)

User

Método	Camino	Acción
Correo	/API/V1/Registrarse	Realiza el registro de un nuevo usuario
Correo	/API/V1/Sesión	Realiza la autenticación del usuario
Conseguir	/API/V1/usuario/perfil	Rescate de la información del usuario

Gyms

Método	Camino	Acción
Correo	/API/V1/gimnasios	Registre un nuevo gimnasio (solo administrador)
Conseguir	/API/V1/cerca	Busque las academias proxmia basadas en la ubicación del usuario
Conseguir	/API/V1/Buscar	Buscar academias

Check-Ins

Método	Camino	Acción
Correo	/API/V1/CHECK-INS	Realiza el registro de un nuevo check-in
Conseguir	/API/v1/check -ins/user/: userId/History	Rescata el historial de registros del usuario
Conseguir	/API/V1/check -ins/User/: UserID/Metrics	Rescata las métricas de registro del usuario
Parche	/API/V1/check-ins/: checkinid/validar	Valida un check-in cuando llegas al gimnasio

Aplicación con DDD en .NET C#

 /src
  /Domain
    - Biblioteca de Classes
    - Entidades, Agregados, Repositórios (Interfaces), Serviços de Domínio
  /Application
    - Biblioteca de Classes
    - Comandos, Consultas, Manipuladores
  /Infrastructure
    - Biblioteca de Classes
    - Persistência, Repositórios (Implementações), Serviços Externos
  /Shared
    - Biblioteca de Classes
    - DTOs, Eventos, Exceções Comuns
  /API
    - WebAPI
    - Controladores, Configuração de Roteamento

1. Dominio

• Tipo de proyecto: biblioteca de clases

• Responsabilidad: contiene las reglas comerciales fundamentales y la lógica central del sistema, incluidas entidades, objetos de valor, agregados y servicios de dominio.

2. Compartido

• Tipo de proyecto: biblioteca de clases

• Responsabilidad: contiene componentes reutilizables en toda la aplicación, como DTTS, eventos de dominio, excepciones comunes, etc.

3. Infra (infraestructura) y aplicación

<<<<<< Cabeza

• Infraestructura: =======
• Infraestructura:

Origen/Main - Tipo de proyecto: Biblioteca de clases

 - ***Responsabilidade:*** Implementa componentes de infraestrutura, como persistência de dados (contextos de banco de dados, repositórios concretos), serviços externos e outras dependências que suportam a aplicação.

<<<<<< Cabeza

• Aplicación: =======
• Solicitud:

Origen/principal

 - ***Tipo de Projeto:*** Biblioteca de Classes

- ***Responsabilidade:*** Orquestra a execução das operações de negócio, utilizando comandos e consultas (em uma abordagem CQRS). Esta camada coordena a comunicação entre a camada de domínio e outras camadas.

4. API

• Tipo de proyecto: webapi

• Responsabilidad: exhibir puntos finales HTTP para clientes externos, como aplicaciones frontales u otros servicios. Incluye controladores que reciben solicitudes HTTP y orquestan la ejecución de comandos y consultas.

RF (requisitos funcionales)

• Debe ser posible que el usuario se registre;
• Debería ser posible que el usuario se autentique;
• Debería ser posible obtener el perfil de un usuario registrado;
• Debe ser posible obtener el número de check-in realizado por el cliente registrado;
• Debería ser posible que el cliente busque gimnasios cercanos;
• Debería ser posible que el usuario busque al cliente por su nombre;
• Debería ser posible que el cliente se registre en un gimnasio;
• Debería ser posible validar el check-in de un cliente;
• Debería ser posible registrar un gimnasio;
• Debería ser posible que el cliente obtenga su historial de check-in
• Debería ser posible obtener el número de verificadores realizados por el cliente iniciado

RN (reglas comerciales)

• El usuario no debe registrarse con un correo electrónico duplicado;
• El usuario no puede hacer 2 check-in el mismo día;
• El usuario no debe registrarse si no cierre (100 metros) del gimnasio;
• El check-in solo se puede validar hasta 20 minutos después de ser creado;
• El check-in solo puede ser validado por los administradores;
• El gimnasio solo el poder registrado por los administradores;

RNF (requisitos no funcionales)

• La contraseña del usuario debe estar encriptada
• Los datos de la aplicación deben persistir en Bacno Postgres SQL;
• Todas las listas de datos deben ser página con 20 elementos por página;
• El usuario debe ser nominado por Token JWT (JSON Web Token);