refactor: padronizar dominios service-types e documents

[euAllanDev]

#732

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 7061f989-f1fc-4333-a9b9-3932aa641b9b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 732-8---refatoração-do-domínio-service-types-documents

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[jefter-dev]

Esse ajuste resolve a rota, mas ainda mantém o domínio antigo service-areas acoplado ao controller.

Como a issue pede padronização de nomenclatura e separação de responsabilidades, acredito que o ideal seria renomear o domínio para service-types de forma consistente: controller, service, repository, DTOs e Swagger.

Manter /service-areas junto com /service-types só faria sentido como compatibilidade temporária.

[jefter-dev]

Esse teste cobre /service-types, mas ainda mantém toda a nomenclatura como ServiceArea.

Como a issue pede padronização, o ideal seria renomear também testes, métodos, services e DTOs para ServiceType.

[jefter-dev]

A alteração está melhor alinhada com a separação do domínio documents, pois remove o fetch direto no componente e passa a usar listPatientDocuments.

Só ajustaria alguns pontos: remover a interface FileItem se não for mais usada, trocar o useState de typeFilter por uma constante caso ele não seja alterado na tela, e usar file.id como key no map em vez do índice.

[jefter-dev]

A estrutura da página dentro de domains/service-types/pages está alinhada com a separação por domínio.

Só observaria que o formulário ainda usa a nomenclatura antiga area no campo, register e errors. Como a issue pede padronização para service-types, o ideal seria usar um nome mais coerente, como name, caso a API/schema já permita essa alteração.

[jefter-dev]

Esse axios.ts parece estar abaixo do padrão atual da dev.

A versão da dev já possui interceptors, tratamento de 401, remoção de sessão, redirect e createDocumentsAPI. Essa alteração simplificada pode causar regressão, principalmente nos fluxos autenticados e nos documentos.

Sugiro manter a estrutura da dev e adaptar os novos domínios sobre ela, em vez de substituir por essa versão reduzida.

[euAllanDev]

Fiz os ajustes seguindo exatamente o ponto levantado no review.

Antes a branch tinha resolvido o endpoint /service-types, mas o domínio ainda permanecia acoplado à nomenclatura antiga ServiceArea. Agora padronizei isso de forma consistente no backend, renomeando controller, implementação, service, repository, model, mapper, DTOs, exception handler e teste para ServiceType. Também atualizei os textos do Swagger para refletirem tipo de atendimento como domínio principal. Mantive /service-areas apenas como compatibilidade temporária, enquanto /service-types fica como rota padronizada.
No frontend, ajustei o domínio service-types para parar de carregar a semântica antiga de area como contrato interno. A estrutura já estava separada por domínio, mas o formulário, hooks, types e schemas ainda usavam area. Padronizei isso para name no domínio frontend e deixei a adaptação com o backend concentrada nos proxies do app, evitando espalhar contrato legado no restante da aplicação.
Também apliquei o ajuste sugerido em fileViewer.tsx: removi o useState desnecessário para typeFilter e troquei a key do map para file.id, mantendo a tela alinhada ao domínio documents sem fetch direto no componente.
Sobre o axios.ts, reforcei a infra usada pelos novos proxies para reduzir o risco de regressão apontado no review, adicionando interceptor de resposta, tratamento de 401, limpeza de sessão e createDocumentsApi, em vez de manter uma versão excessivamente simplificada.
Validação executada:

• ServiceTypeControllerTest: passou
• PatientDocumentsTests: passou

Com isso, o ajuste deixa de ser só uma troca de rota e passa a atender de fato a padronização de nomenclatura e separação de responsabilidades pedidas na issue e no review.