mirror of
https://codeberg.org/jsilveira/br.dev.jsilveira.coresync.git
synced 2026-06-11 18:05:06 +00:00
53 lines
No EOL
3.2 KiB
Markdown
53 lines
No EOL
3.2 KiB
Markdown
# 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
|
|
|
|
1. **Modelagem Baseada em Records:** Imutabilidade garantida por design. Toda transição de estado no domínio produz uma nova instância (`copy-on-write`).
|
|
2. **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.
|
|
3. **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.
|
|
4. **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`).
|
|
5. **POJO Services:** Os casos de uso (`application/service`) não possuem anotações do framework (`@Service`). Eles são instanciados e injetados via `@Configuration` nos módulos.
|
|
6. **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
|
|
|
|
```text
|
|
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.** |