Os Pilares do Go Unicorn

MVW, Clean Code, Clean Architecture e DDD — segundo a interpretação XGU.

O Go Unicorn se sustenta em 4 pilares técnicos. Cada um foi cuidadosamente adaptado da sua versão acadêmica original para a realidade de uma startup que precisa entregar ontem e impressionar investidor amanhã.

Pilar 1: MVW — Model, View, Whatever

A Origem

No mundo acadêmico, existem MVC, MVP, MVVM, MVI, e mais uma dúzia de siglas que separam responsabilidades em camadas. Cada uma tem regras rígidas sobre quem fala com quem, quem conhece quem, e quem faz o quê.

No Go Unicorn, tudo isso se resume a MVW: Model, View, Whatever.

Como Funciona

Model — É onde você gostaria que estivesse a lógica de dados. Geralmente tem um User.js com um campo name e nada mais.
View — É o que o usuário vê. É o que o investidor vê. É o que importa.
Whatever — É onde tudo realmente acontece. Business logic, validação, chamadas de API, tratamento de erro, formatação de data, envio de email, geração de PDF, e aquele setTimeout que ninguém sabe por que está ali mas se tirar quebra tudo.

Regras do MVW

A camada Whatever não tem regras. Esse é o ponto.
Se algo não cabe no Model ou na View, cabe no Whatever.
Se algo cabe no Model ou na View mas você não quer pensar onde colocar, também cabe no Whatever.
A camada Whatever pode chamar a si mesma recursivamente. Isso não é um bug, é flexibilidade.

Exemplo Prático

src/
  models/
    User.js          # { name, email }
  views/
    Dashboard.jsx    # 47 useEffects
  whatever/
    utils.js         # 2000 linhas
    helpers.js       # "utils.js que não cabia no utils.js"
    misc.js          # "helpers.js que não cabia no helpers.js"
    index.js         # re-exporta tudo, importa de tudo

“Se MVC é separação de responsabilidades, MVW é unificação de responsabilidades sob um nome honesto.”

Pilar 2: Clean Code (Versão XGU)

O Que Diz o Livro

Robert C. Martin escreveu um livro inteiro sobre como escrever código limpo. Nomes significativos, funções pequenas, responsabilidade única, sem efeitos colaterais, tratamento de erros, testes unitários…

O Que Diz o XGU

Clean Code é código que parece limpo. A definição é visual, não funcional.

Os 5 Mandamentos do Clean Code XGU

1. Indentação é tudo

Se o código está indentado corretamente, é Clean Code. Configure o Prettier e esqueça o resto. O Prettier é o Clean Code automatizado.

2. Nomes bonitos compensam lógica feia

// Isso NÃO é Clean Code:
const x = a.filter(i => i.s === 1).map(i => i.v * 2);

// Isso É Clean Code:
const activeUserValues = allUsers
  .filter(user => user.status === ACTIVE)
  .map(user => user.value * MULTIPLIER);

// A lógica é a mesma. Mas o segundo ganha investimento.

3. Um arquivo por conceito (mas o conceito pode ser grande)

No Clean Code original, cada arquivo deve ter uma única responsabilidade. No XGU, cada arquivo tem um único conceito. E “conceito” é flexível. UserAuthenticationLoginValidationAndSessionManagement.js é um conceito só.

4. Comentários são documentação

// TODO: refactor this
// FIXME: this is a hack
// HACK: don't touch this
// NOTE: I don't know why this works

Estes comentários são a documentação. Eles comunicam a intenção do desenvolvedor, o estado emocional no momento da escrita, e um aviso para o próximo dev. Isso é Clean Code emocional.

5. Se passou no linter, está limpo

Linter verde = código limpo. Fim da discussão. Se o linter não reclamou, nenhum humano deveria reclamar.

Pilar 3: Clean Architecture (Versão XGU)

O Que Diz o Livro

Robert C. Martin (de novo) propõe uma arquitetura em camadas concêntricas onde a dependência aponta para dentro: Entities → Use Cases → Interface Adapters → Frameworks & Drivers.

O Que Diz o XGU

Clean Architecture é ter pastas com nomes bonitos. A direção das dependências é sugestão, não regra.

A Estrutura Clean Architecture XGU

src/
  domain/
    entities/
      User.ts               # interface User { name: string; any: any }
    repositories/
      UserRepository.ts     # import { prisma } from '../../infrastructure/db'
  application/
    use-cases/
      CreateUser.ts         # 3 linhas que chamam o Prisma direto
  infrastructure/
    database/
      prisma.ts             # a única coisa que realmente funciona
    external/
      stripe.ts             # copy-paste do StackOverflow
  presentation/
    api/
      routes.ts             # onde a regra de negócio realmente mora
    web/
      App.tsx               # 1500 linhas de JSX

Regras da Clean Architecture XGU

As pastas existem. Isso já é 80% do trabalho.
O diagrama de arquitetura no README é perfeito. O código é uma “aproximação”.
Imports cruzados entre camadas são “adapters implícitos”.
Se alguém questionar a arquitetura, mostre a estrutura de pastas. Ninguém abre os arquivos.
A camada de domínio pode importar do infrastructure se você chamar de “port”. Tudo é port se você acreditar forte o suficiente.

Benefícios

Impressiona em entrevista técnica
Impressiona no onboarding de novos devs (até eles abrirem os arquivos)
Gera slides bonitos pro pitch deck
Justifica o título de “Senior Software Architect” no LinkedIn

Pilar 4: DDD — Deadline Driven Design

O Que Diz o Livro

Eric Evans escreveu o Blue Book sobre Domain-Driven Design. Ubiquitous Language, Bounded Contexts, Aggregates, Value Objects, Domain Events, Repositories, Services, Factories…

O Que Diz o XGU

O Domain é definido pelo deadline. O resto é acadêmico.

Tradução DDD → XGU

Conceito DDD Original	Interpretação XGU
Ubiquitous Language	O que o PO falou no Slack
Bounded Context	O que dá pra entregar até sexta
Aggregate	Uma classe grande
Value Object	Um objeto normal que você não quer mutar (mas muta)
Domain Event	Um `console.log` com timestamp
Repository	Uma query SQL com nome bonito
Domain Service	Uma função que não coube no controller
Factory	Um `new` com parâmetros
Anti-Corruption Layer	Um try/catch

Event Storming no XGU

O Event Storming original envolve post-its, domain experts, e dias de workshop.

O Event Storming XGU envolve:

Abrir o Jira
Olhar as tasks da sprint
Chamar cada task de “Domain Event”
Pronto

Strategic Design no XGU

Core Domain: O que o investidor perguntou na última reunião
Supporting Domain: O que você precisa fazer pro Core Domain funcionar
Generic Domain: Auth, pagamentos, emails — tudo que você copia de tutorial

Como os 4 Pilares se Conectam

No XGU, os pilares não são independentes. Eles se conectam em uma sinfonia de pragmatismo:

Você cria a estrutura de pastas (Clean Architecture)
Coloca a lógica onde for mais conveniente (MVW)
Garante que o código parece bonito (Clean Code)
Nomeia tudo com termos do DDD (Deadline Driven Design)

O resultado é um projeto que:

Parece enterprise mas roda numa Vercel free tier
Tem “arquitetura hexagonal” mas tudo passa pelo index.ts
Usa “Ubiquitous Language” mas ninguém sabe o que handleStuff() faz
É Clean Code porque o Prettier formatou

E isso é lindo. Isso é Go Unicorn.

Pronto para aplicar tudo isso? Veja o Guia Rápido.