Domain-Driven Design (DDD) & Feature-Sliced Design (FSD)
A arquitetura do frontend combina contextos delimitados de Domain-Driven Design (DDD) com a modularidade de Feature-Sliced Design (FSD) para alcançar aplicações escaláveis, robustas e desacopladas.
1. Conceito Arquitetônico & Visão Geral
Domain-Driven Design (DDD)
O Domain-Driven Design (DDD) organiza a lógica de negócios complexa em módulos isolados e centrados no domínio, chamados Contextos Delimitados (Bounded Contexts), onde cada domínio possui a integridade de seu modelo e vocabulário. Isso evita o acoplamento forte entre diferentes áreas da aplicação e mantém os modelos focados.
Feature-Sliced Design (FSD)
O Feature-Sliced Design (FSD) é uma metodologia arquitetônica moderna projetada especificamente para aplicações frontend. Ele segrega o código em uma hierarquia padronizada de camadas, fatias (slices) e segmentos, estabelecendo fluxos de dependência unidirecionais estritos, evitando importações circulares e garantindo alta modularidade.
Ao combinar a segregação de contexto do DDD com a separação de camadas do FSD, nossas aplicações permanecem fáceis de manter, mesmo à medida que o tamanho das equipes e os conjuntos de recursos crescem.
2. Utilização Específica do Projeto
No tupynambalucas.dev, a combinação de DDD e FSD governa tanto a estrutura de pastas quanto as regras de importação:
A. Segregação de Contexto Delimitado
O monorepo é dividido em contextos distintos (instance/ e portal/) no nível raiz. Esses limites garantem que as operações da comunidade (Instance) e os fluxos de trabalho de integração global de SaaS (Portal) permaneçam estrutural e logicamente independentes. Tokens de design compartilhados ou ativos de marca são importados exclusivamente do workspace @tupynambalucas-studio/design.
B. Hierarquia de Camadas de Frontend (FSD)
Dentro de cada aplicação React de frontend, a base de código é estruturada em camadas arquitetônicas estritas:
src/
├── domains/ <-- Camada de Domínios Globais (ex: auth, product, cycle)
│ └── auth/
│ ├── hooks/
│ └── auth.store.ts
├── features/ <-- Fluxos de trabalho do usuário e módulos interativos (ex: shop, admin)
│ ├── shop/
│ │ ├── domains/ <-- Domínios privados específicos de feature (ex: cart)
│ │ └── components/
│ └── admin/
└── shared/ <-- Utilitários reutilizáveis agnósticos e componentes comuns
└── ui/ <-- Botões, Modais, Loaders, componentes de Input
- Domínios Globais (
src/domains): Representam conceitos de negócios centrais (ex:auth,product,cycle). Esta camada abriga stores de estado do Zustand específicos do domínio, clientes de API do Axios e hooks de orquestração de domínio. - Features (
src/features): Abrigam fluxos de trabalho do usuário e módulos interativos de aplicativos (ex:admin,shop). As features orquestram múltiplos domínios subjacentes para entregar fluxos de aplicação de alto nível, mas permanecem estritamente isoladas de outras features. - Domínios Privados Específicos de Feature (
src/features/*/domains): Domínios dedicados contidos dentro de uma feature específica (como um domínio privadocartdentro da featureshop). Isso mantém o namespace global limpo e evita a poluição do domínio global. - Camada de UI Compartilhada (
src/shared/ui): Apresenta blocos de construção de UI reutilizáveis e agnósticos de domínio (como loaders, botões, inputs e modais) que contêm zero lógica de negócios.
3. Limites Estritos de Importação
Para manter a escalabilidade de longo prazo, impomos limites estritos de importação unidirecional:
- Fluxo Unidirecional: O código só pode importar de camadas localizadas abaixo dele na hierarquia:
Features->Domains->Shared. - Sem Importações para Cima: Domínios globais ou componentes compartilhados são estritamente proibidos de importar de features.
- Sem Importações Cruzadas de Features: Módulos de feature não podem importar diretamente de outros módulos de feature; eles só podem colaborar por meio de orquestração de páginas de alto nível ou assinando domínios globais compartilhados.