Clean Architecture em aplicativos mobile com React Native

Clean Architecture organiza o software para ser independente de frameworks, testável e fácil de evoluir. Em React Native, ela ajuda a separar regras de negócio da interface e da infraestrutura (APIs, banco local), reduzindo acoplamento e aumentando previsibilidade.

⸻

O que é Clean Architecture?

É um conjunto de princípios que defende separação em camadas com dependências apontando sempre para dentro (do externo para o interno), protegendo o núcleo do negócio de detalhes de implementação. O objetivo é facilitar troca de tecnologias (UI, banco, API) sem reescrever o domínio.

Ideias-chave: • Independência de framework: React/Redux/Zustand são detalhes de entrega. • Testes primeiro: regras de negócio testadas sem UI ou rede. • Separação de preocupações: domínio, casos de uso, interface e infraestrutura bem definidos. • Dependência invertida: camadas externas conhecem contratos internos, nunca o contrário.

⸻

Por que aplicar em React Native?

Apps mobile crescem rápido: múltiplas telas, offline, sincronização, cache, autenticação, analytics. Clean Architecture traz: 1. Escalabilidade: features novas sem quebrar as existentes. 2. Testabilidade: domínio e casos de uso isolados de UI e rede. 3. Flexibilidade tecnológica: trocar client HTTP, banco local ou serviço remoto sem tocar no domínio. 4. Colaboração: papéis claros entre frontend, backend e QA.

⸻

Estrutura sugerida (alto nível)

/app
  /domain        → entidades, value objects, regras de negócio, contratos (ports)
  /application   → casos de uso (use cases), orquestração de regras
  /infrastructure→ adapters (HTTP, SQLite/AsyncStorage, Firebase), mapeamentos
  /presentation  → UI React Native (Views), gerência de estado (VM/MVI/store)
  /core          → utilitários, DI, logging, config

• Domain: o coração do app; não depende de React ou bibliotecas externas. • Application (use cases): coordena regras de negócio e conversa via ports com o mundo externo. • Infrastructure: implementa os adapters concretos (APIs, persistência, notificações, analytics). • Presentation: telas e componentes; exibe estado e dispara intenções (MVVM/MVI podem viver aqui).

A regra de ouro: Presentation → Application → Domain (setas para dentro). Infrastructure depende de Application/Domain, nunca o contrário.

⸻

Como o fluxo acontece 1. Usuário interage com a Presentation (View/Store). 2. A apresentação dispara um Use Case em Application. 3. O Use Case aplica regras do Domain e chama ports para obter/persistir dados. 4. Infrastructure fornece os adapters concretos que implementam os ports. 5. O resultado retorna à Presentation, que renderiza o novo estado.

Esse ciclo garante que mudanças em UI ou rede não contaminem o núcleo do negócio.

⸻

Benefícios práticos • Evolução segura: refatorar UI/infra sem reescrever regras. • Testes rápidos: Use Cases e Domain testados sem mock pesado de UI. • Onboarding fácil: novas pessoas entendem onde cada peça pertence. • Portabilidade: parte do núcleo pode ser reaproveitada (web/mobile/server).

⸻

Boas práticas 1. Domínio sem dependências externas: sem imports de React, fetch ou libs específicas. 2. Contratos (ports) estáveis: defina interfaces claras para repositórios/serviços. 3. Use Cases pequenos e expressivos: cada caso de uso deve ter propósito único. 4. Mappers/DTOs na borda: traduções entre API e Domain acontecem na Infrastructure. 5. Tratamento consistente de erros: converta falhas técnicas em erros de domínio compreensíveis. 6. Config e DI centralizados: injete adapters (API, cache, logger) na composição do app. 7. Estados explícitos na Presentation: carregando/erro/vazio/sucesso visíveis e testáveis. 8. Observabilidade: logging/telemetria por caso de uso e por feature.

⸻

Quando usar Clean Architecture • Produtos médios/grandes com roadmap extenso e equipe múltipla. • Apps que precisam funcionar offline, sincronizar dados e lidar com estados complexos. • Projetos que visam longevidade e troca de fornecedores (ex.: migrar de Firebase para Supabase/SQLite).

Em MVPs muito pequenos, comece simples; adote a estrutura aos poucos conforme o escopo cresce.

⸻

Relação com MVVM/MVI/MVC • Clean Architecture é um guarda-chuva de princípios. MVVM/MVI/MVC são padrões de apresentação que podem ocupar a camada Presentation. • Escolha MVVM quando quiser ViewModels ricos em estado derivado. • Escolha MVI quando precisar de fluxo unidirecional com rastreabilidade forte. • MVC pode ser útil em times que já falam MVC e pedem um Controller explícito.

O importante é manter o núcleo (Domain/Application) protegido e os detalhes (Presentation/Infrastructure) substituíveis.

⸻

Trade-offs e cuidados • Mais pastas e cerimônia: exige disciplina para não burocratizar. • Curva de aprendizado: demanda alinhamento do time em nomes e contratos. • Overengineering em MVPs: introduza conforme há sinais de crescimento/complexidade.

⸻

Conclusão

Aplicar Clean Architecture em React Native traz clareza, testabilidade e flexibilidade. Ao isolar Domain e Application dos detalhes de UI e Infrastructure, você reduz custos de manutenção e aumenta a vida útil do produto.

Em uma frase: proteja seu negócio do seu app — frameworks e serviços mudam, sua regra de negócio fica. Mantendo dependências para dentro, você constrói um mobile pronto para escalar e durar.