Pular para o conteúdo principal

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 privado cart dentro da feature shop). 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:

  1. Fluxo Unidirecional: O código só pode importar de camadas localizadas abaixo dele na hierarquia: Features -> Domains -> Shared.
  2. Sem Importações para Cima: Domínios globais ou componentes compartilhados são estritamente proibidos de importar de features.
  3. 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.