jsilveira
b2314bcf36
- Create UserController, WorkoutController, and SessionController to expose application use cases via REST endpoints - Add request and response DTOs alongside web mappers for the User, Workout, and Session domains - Introduce GlobalExceptionHandler to handle domain-specific exceptions and return HTTP 400 Bad Request responses - Add Springdoc OpenAPI and Scalar dependencies to build.gradle for API documentation - Configure OpenAPI and Scalar settings in the base and dev application properties |
||
|---|---|---|
| gradle/wrapper | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| agents.md | ||
| build.gradle | ||
| compose.yaml | ||
| gradlew | ||
| gradlew.bat | ||
| README.md | ||
| settings.gradle | ||
CoreSync Backend
CoreSync é a API backend desenvolvida para um aplicativo mobile de gestão de treinos e academia.
Este projeto tem caráter acadêmico e foi desenvolvido como parte dos requisitos do 7º semestre do IFRS - Campus Vacaria. O foco principal desta implementação é explorar e aplicar conceitos avançados de engenharia de software, garantindo um código altamente testável, escalável e de fácil manutenção.
Stack Tecnológico
A base de tecnologia foi escolhida para alinhar a expressividade do Groovy com a robustez do ecossistema Spring:
- Linguagem: Groovy (Closures, Records, sintaxe enxuta)
- Runtime: Java 26 (toolchain via Gradle)
- Framework: Spring Boot (Web, Security, Data MongoDB)
- Banco de Dados: MongoDB
- Comunicação: RESTful (JSON) + Autenticação Stateless (JWT)
- Cliente-Alvo: App mobile construído em React Native
Arquitetura e Padrões de Projeto
O CoreSync foi arquitetado como um Monolito Modular, fundamentado nos princípios de Domain-Driven Design (DDD) e na Arquitetura Hexagonal (Ports & Adapters).
A premissa absoluta do projeto é o isolamento total da Regra de Negócio. As camadas de Domínio (domain) e Aplicação (application) são 100% agnósticas de framework, infraestrutura, banco de dados ou protocolos de rede (HTTP).
Diretrizes Fundamentais
- Modelagem Baseada em Records: Imutabilidade garantida por design. Toda transição de estado no domínio produz uma nova instância (
copy-on-write). - Validação Fail-Fast: Todas as invariantes de negócio são validadas nos construtores compactos dos
records. É impossível instanciar um objeto de domínio em estado inválido. - Domínio Rico (Rich Domain): A lógica pertence às entidades. Serviços de aplicação apenas orquestram as transições, nunca concentram regras de negócio.
- Sem Lombok, Sem Magia Oculta: O projeto abole o uso de Lombok, tirando proveito dos recursos nativos do Groovy (construtores por mapa, propriedades automáticas e
@Slf4j). - POJO Services: Os casos de uso (
application/service) não possuem anotações do framework (@Service). Eles são instanciados e injetados via@Configurationnos módulos. - Desacoplamento de IDs: A geração de identificadores (UUID) ocorre antes da persistência, na camada de aplicação, delegando ao banco de dados apenas o armazenamento.
Estrutura de Diretórios
src/main/groovy/br/dev/jsilveira/coresync/
├── domain/ # Coração do software (Records, Value Objects e Exceptions)
├── application/ # Casos de uso (Services) e contratos (Ports In/Out)
├── adapter/ # Conexão com o mundo externo (Controllers, Repositories, Entities)
└── config/ # Injeção de dependências (Bean wiring)
Autenticação e Segurança
Todas as requisições (exceto rotas públicas) exigem validação via token JWT.
A extração do usuário logado e a validação do token ocorrem na borda externa (adaptador web). O domínio recebe apenas os IDs processados, desconhecendo por completo o conceito de token ou contexto de segurança web.