# ARCHITECTURE_ANALYSIS.md

## Visão geral
O projeto `42net` é um site/landing pages renderizado no servidor (PHP) sem camada de back-end de domínio (não há modelos, serviços ou repositórios de negócio identificáveis). Cada página PHP funciona como um “template” que compõe um layout comum por `include` (cabeçalho, navegação e rodapé) e entrega HTML+CSS+JS ao navegador.

## Estilo arquitetural
- Monólito de templates (server-side rendered “static site” em PHP).
- Modularidade apenas por *partials* de view: o layout é decomposto em `includes/header.php`, `includes/nav.php` e `includes/footer.php`.
- Não há arquitetura de microservices nem separação por domínios; não há APIs internas.

## Separação de camadas
Camadas são implícitas e não seguem um desenho clássico:
- Camada de “View” (principal): páginas PHP contendo HTML e marcação Tailwind.
- Camada de “Layout/Componentes”: `includes/header.php`, `includes/nav.php` e `includes/footer.php`.
- Camada de “Controller”: não identificada como componente (as páginas em si executam o papel de controller muito leve ao definir `$pageTitle` e `$pageDescription` e incluir o layout).
- Camada de “Model/Domain”: não identificada.
- Camada de “Data Access”: não identificada.

Observação importante: o “backend” observado é basicamente composição de template e variáveis de metadados, não lógica de domínio nem integração com banco/serviços internos.

## Padrão de organização do backend
- “Backend” = PHP por página.
- Organização por *includes* de layout.
- Páginas seguem o mesmo padrão: definem `$pageTitle` e `$pageDescription`, fazem `include __DIR__ . '/includes/header.php';`, depois `include __DIR__ . '/includes/nav.php';` e por fim `include __DIR__ . '/includes/footer.php';`.

Exemplo de acoplamento estrutural: `includes/header.php` depende de variáveis `$pageTitle` e `$pageDescription` para preencher `<title>` e `meta name="description"` (ou usa valores default, caso não existam). Além disso, o `header.php` passou a calcular canonical e metadados sociais com base no request.

## Padrão do frontend
- Frontend é servido como HTML estático com:
  - Tailwind CSS via CDN (`https://cdn.tailwindcss.com`) e classes utilitárias na marcação.
  - Font Awesome via CDN para ícones.
  - Google Fonts (Inter) via CDN.
  - Pequenos scripts JavaScript “inline” em cada página/pacote de layout:
    - `includes/nav.php`: script para alternar menu mobile (`mobile-menu-toggle`).
    - `tutorial.php`: script para alternar expansão de seções/artigos (`.toggle-article` -> `.article-details`).
    - `index.php`: script para alternar opacidade de imagens conforme scroll.
  - Metadados SEO técnicos centralizados em `includes/header.php`:
    - canonical
    - OpenGraph/Twitter cards
    - schema básico (Organization) em JSON-LD

Não há SPA (React/Vue/Angular) nem bundler (ex.: Vite/Webpack). Scripts permanecem no HTML final.

## Comunicação entre frontend/mobile e backend
- Não existe comunicação via API (fetch/AJAX) nem endpoints REST/SOAP identificáveis nessa estrutura.
- Navegação entre “páginas” ocorre via links HTTP diretos (`href="index.php"`, `href="tutorial.php"`, etc.).
- Qualquer “integração” é via links externos no HTML:
  - WhatsApp (wa.me / api.whatsapp.com)
  - e-mail (mailto:)
  - cPanel (Central do Cliente)
  - Google Maps

Não há aplicação mobile dedicada no repositório; portanto, também não há comunicação frontend/mobile -> backend.

## Padrões identificados (ou ausentes)
- Padrões claramente presentes:
  - Composição de layout por `include` (partial templates).
  - *DRY parcial* no nível de header/nav/footer.
  - Interações front-end em JavaScript vanilla e manipulação DOM por seletores CSS.
- Padrões clássicos, mas essencialmente “não aplicados”:
  - MVC: não há separação nítida em `controllers/models/views`. As páginas fazem o papel de controlador (mínimo) e view ao mesmo tempo.
  - Services/Repositories: não identificados (nenhum acesso a dados ou lógica de domínio).

## Pontos fortes da arquitetura
- Simplicidade: fácil de hospedar e renderizar diretamente com PHP/Apache.
- Reuso do layout: `includes/header.php`, `includes/nav.php` e `includes/footer.php` evitam duplicação do HTML de estrutura.
- Consistência: todas as páginas seguem um padrão homogêneo (metadados -> header -> nav -> conteúdo -> footer).
- UX com Tailwind: o uso de Tailwind permite criar páginas rapidamente mantendo coesão visual via classes utilitárias.

## Problemas arquiteturais
- Ausência de separação de responsabilidades: cada página mistura:
  - definição de metadados,
  - estrutura do layout,
  - conteúdo da página,
  - e scripts (em alguns casos).
- Escalabilidade limitada:
  - conforme novas páginas forem surgindo, o conteúdo HTML vai se tornar grande e difícil de manter.
- Dependências front distribuídas:
  - Tailwind/FontAwesome/Google Fonts são carregados via layout comum, o que é prático, mas também acopla todas as páginas a esses providers (ex.: se mudar Tailwind, precisa alterar `includes/header.php`).
- Scripts inline por página:
  - dificulta cache, versionamento e testes.
  - aumenta chance de divergência de lógica UI ao longo do tempo.

## Acoplamentos perigosos (acoplamentos “de verdade” no código)
- Acoplamento por contrato implícito de variáveis globais:
  - `includes/header.php` espera que `$pageTitle` e `$pageDescription` existam (ou então cai em defaults). Se algum desenvolvedor esquecer de definir essas variáveis, metadados podem ficar inconsistentes sem erro explícito.
- Acoplamento estrutural do layout:
  - `index.php`/`tutorial.php` assumem que IDs/classes específicas existem no HTML (ex.: `hero-section-1`, `hero-image-1`; `.toggle-article`, `.article-details`). Mudanças no markup podem quebrar o comportamento.
- Acoplamento de CSS/JS aos seletores e classe utilitária Tailwind:
  - o comportamento do menu mobile e expansão de artigos depende de seletores e classes do HTML renderizado.

## Recomendações arquiteturais (alto nível)
- Se houver evolução para funcionalidades dinâmicas:
  - separar “controller” (PHP) de “view” (templates), criando uma camada de roteamento ou helpers consistentes.
  - extrair JS inline para arquivos versionados (mesmo que simples), para reduzir acoplamento por markup e melhorar cache.
- Se o projeto crescer em volume:
  - padronizar componentes (ex.: cards/sections) e criar convenções para scripts por componente.
- Se surgir persistência (banco/serviços):
  - introduzir camadas de `repositories` e `services` para desacoplar lógica de domínio de acesso a dados.