FrontendReact

DDD para Frontend: quando e por que investir em Domain-Driven Design

DDD para Frontend: quando e por que investir em Domain-Driven Design

Introdução: por que falar de DDD no Frontend?

No universo frontend, as aplicações crescem em complexidade. Componentes se multiplicam, regras de negócio se espalham e gerenciar estados vira um desafio. Domain-Driven Design (DDD) surge do backend para organizar e dar sentido ao código. Mas será que vale a pena aplicar DDD no frontend? Neste post, vamos contextualizar a necessidade, mostrar conceitos essenciais e apresentar exemplos práticos.

O que é Domain-Driven Design?

Domain-Driven Design é uma abordagem que prioriza o domínio da aplicação (regras de negócio) e a colaboração entre desenvolvedores e especialistas. Seus pilares incluem:

  • Entidades e Value Objects: modelos que representam objetos do domínio e seus valores.

  • Aggregates: limites que garantem consistência transacional.

  • Services e Repositories: abstrações para comportamentos e persistência.

  • Bounded Contexts: divisão da aplicação em áreas bem-definidas.

Como DDD se encaixa no Frontend

1. Bounded Contexts no Frontend

Separe sua aplicação em contextos (por exemplo: Auth, Carrinho, Catálogo). Cada contexto tem sua própria pasta e modelos.

/src
  /auth
    AuthService.ts
    UserEntity.ts
  /cart
    CartService.ts
    CartItemVO.ts

2. Modelos ricos com Entities e Value Objects

Em vez de usar objetos literais, crie classes:

// UserEntity.ts
export class UserEntity {
  constructor(
    public readonly id: string,
    public name: string,
    private email: string
  ) {}
 
  changeEmail(newEmail: string) {
    if (!newEmail.includes('@')) throw new Error('E-mail inválido');
    this.email = newEmail;
  }
}
// CartItemVO.ts
export class CartItemVO {
  constructor(
    public readonly productId: string,
    public readonly quantity: number
  ) {}
 
  getTotalPrice(unitPrice: number) {
    return unitPrice * this.quantity;
  }
}

3. Serviços e Repositórios como abstrações

Trate chamadas HTTP ou state management como repositórios:

// CartRepository.ts
import axios from 'axios';
import { CartItemVO } from './CartItemVO';
 
export class CartRepository {
  async fetchItems(): Promise<CartItemVO[]> {
    const { data } = await axios.get('/api/cart');
    return data.map((i: any) => new CartItemVO(i.productId, i.qty));
  }
}

Boas práticas para implementar DDD no Frontend

  1. Isolar lógicas de negócio: mantenha serviços e entidades separados de componentes de UI.

  2. Nomear consistentemente: use termos do domínio, não abreviações vagas.

  3. Manter pastas coesas: um contexto = uma pasta com modelos, serviços e hooks.

  4. Testes unitários nos modelos: valide regras de negócio diretamente nos Entities e VOs.

Possíveis armadilhas e como evitá-las

Erro ComumComo Evitar
Excesso de abstraçõesAvalie a complexidade real antes de criar camadas
Misturar estado de UI com domínioUse hooks/custom hooks para UI e insira serviços
Definir VOs sem lógicaInclua validações/regras no construtor
Bounded Context não isoladosAdote convenções de import/export restritivas

Conclusão: DDD no Frontend é para você?

DDD no frontend faz sentido quando a aplicação ultrapassa dezenas de componentes e regras de negócio complexas. Projetos pequenos ou protótipos podem sofrer com overhead. Se sua equipe valoriza código organizado, testes focados e colaboração com o time de negócio, DDD traz clareza e escalabilidade.