Squad Front

Appearance

Camadas do Sistema e Contextos ​

Este documento detalha a arquitetura de camadas do sistema, explicando a responsabilidade de cada nível e como elas se comunicam. Essa separação é fundamental para manter a escalabilidade, testabilidade e organização do projeto.

1. Visão Geral ​

Nossa arquitetura é dividida em três camadas principais de contexto, seguindo o princípio de separação de responsabilidades (SoC):

  1. Camada de Aplicação (Application/Infrastructure): O alicerce técnico.
  2. Camada de Funcionalidade (Feature/Business): Onde a lógica de negócio reside.
  3. Camada de Tela (Screen/UI): A interface com o usuário.

2. Visão Detalhada ​

2.1 Camada de Aplicação (Application) ​

Responsabilidade: Fornecer a infraestrutura básica e utilitários globais que sustentam todo o sistema.

Ver Detalhamento e Exemplos (Redux Saga) ->

  • O que contém: Configurações de API (Axios/Fetch), Actions/Sources (chamadas de API), Providers globais (Autenticação, Tema), Utilitários genéricos (formatação de data, logs), Definições de tipos globais.
  • Regras:
    • Não deve conhecer regras de negócio complexas de uma funcionalidade.
    • Deve ser altamente reutilizável em múltiplas funcionalidades.
    • Exemplo: src/api/client.ts, src/actions/auth-actions.ts, src/utils/date-formatter.ts.

2.2 Camada de Funcionalidade (Feature) ​

Responsabilidade: Encapsular toda a lógica de negócio, regras de domínio e integração com serviços para um módulo específico.

Ver Detalhamento e Exemplos (TanStack Query) ->

  • O que contém:
    • Rules/Logic: Funções de validação e processamento de dados do domínio.
    • Hooks de Dados: Custom hooks que gerenciam o estado de dados (TanStack Query).
  • Regras:
    • Não deve conter lógica de UI ou referências a componentes visuais.
    • Deve ser independente da tela onde será usada (uma Rule pode ser usada em múltiplas telas).
    • Exemplo: src/features/teleconsulta/rules/validate-scheduling.ts.

2.3 Camada de Tela (Screen) ​

Responsabilidade: Orquestrar a interface do usuário, capturar interações e exibir dados.

Ver Detalhamento e Exemplos (UI Logic) ->

  • O que contém: Componentes de página (.screen.tsx), Hooks de UI (-screen.hooks.ts), Gerenciamento de estado local da tela, Feedback visual (Toasts, Modais).
  • Regras:
    • Regra de Ouro: A Screen é a única responsável por disparar feedbacks visuais para o usuário.
    • Toda lógica complexa deve ser delegada para o hook da tela ou para a camada de Funcionalidade.
    • Deve consumir componentes do @ptm/design-system.
    • Exemplo: src/screens/appointment/appointment.screen.tsx.

3. Fluxo de Comunicação ​

O fluxo ideal de dependência deve ser sempre: Screen -> Feature -> Application

  • Uma Screen consome Features.
  • Uma Feature consome Application.
  • A Application nunca deve depender de nada acima dela.

4. Por que usamos esse padrão? ​

  • Facilidade de Teste: Podemos testar Rules (lógica de negócio) sem precisar renderizar telas.
  • Manutenção: Se a API mudar, alteramos na Application/Feature. Se o design mudar, alteramos na Screen.
  • Onboarding: Novos desenvolvedores conseguem localizar rapidamente onde uma alteração deve ser feita baseada na natureza da tarefa.