Pular para o conteúdo principal

MDS · Modular Development Style

Manifesto

Os 7 princípios inegociáveis que guiam o MDS. Toda decisão de design da metodologia deriva deles.

Versão 1.1 · Atualizado em 04 de agosto de 2026

MANIFESTO, Modular Development Style

7 princípios que guiam o MDS. Toda decisão de design da metodologia deriva deles. Inviolável.


1. Blocos que se encaixam, não monolitos que se quebram

Todo sistema é uma composição de blocos com responsabilidades claras e interfaces explícitas. Um bloco bem desenhado encaixa em qualquer projeto que aceite seu tipo, independente do porte. Monolitos são proibidos como princípio: até a especificação de um endpoint solitário é um BLOCO-BASE, pequeno mas com encaixe definido.

2. Universal nos conceitos, escalável no artefato

A mesma metodologia descreve um script de 30 linhas e um produto SaaS de 12 módulos. O que muda não é o vocabulário, é a profundidade de cada bloco. Adicionar conceitos novos pra projeto grande gera fragmentação; subtrair conceitos pra projeto pequeno gera ritual cargo-cult. MDS classifica obrigatoriedade, nunca subtrai vocabulário.

3. Obrigatoriedade declarada, nunca presumida

Existem três categorias de bloco: BASE, PLUGIN, STACK. Cada bloco do template carrega sua categoria explícita. Quando um PLUGIN não dispara, o documento declara formalmente N/A: [motivo] em uma linha. Omissão silenciosa é defeito de processo, não economia de esforço. Quem omite paga a dívida no primeiro bug.

4. Gatilhos mecânicos, não julgamento subjetivo

Cada BLOCO-PLUGIN tem gatilho binário: “tem persistência? S/N”. Resposta sim → bloco obrigatório. Resposta não → N/A. Decisão não passa por julgamento estético (“achei que não precisava”). Subjetividade no preenchimento de templates é a raiz da inconsistência operacional.

5. Sistema trabalha pra você, não você pro sistema

(Princípio nascido na construção de um produto multi-módulo da casa e elevado a princípio universal MDS.)

Todo bloco do template responde a 4 perguntas: o que isso automatiza pro usuário? que evento em outro bloco isso dispara? onde cabe um botão “Gerar com IA”? que dados já existem que esse bloco pode CONSUMIR (em vez de pedir pro usuário digitar de novo)? Bloco que só captura sem retornar valor é defeito de design.

6. Cadastro progressivo, nunca bloqueante

(Princípio nascido na construção de um produto multi-módulo da casa e elevado a princípio universal MDS.)

Em todo bloco com campos editáveis, somente o campo identificador é obrigatório. Demais campos são NULL/opcionais por padrão. O sistema USA campos quando preenchidos; AUSÊNCIA nunca bloqueia operação. Forçar preenchimento upfront é hostilidade de UX disfarçada de validação.

7. Tudo é entitlement, nada é hardcoded

(Princípio nascido na construção de um produto multi-módulo da casa e elevado a princípio universal MDS.)

Toda decisão de comportamento, regra de negócio, limite, preço, feature flag, ON/OFF de funcionalidade tem que ser configurável em runtime via UI de admin. Hardcode que exige migration, edição de banco ou deploy pra mudar configuração é defeito de processo, e a regra vale em todos os produtos Modulareasy.


Princípios negativos (14 anti-patterns proibidos)

Esses padrões NUNCA aparecem em sistema construído com MDS:

#Anti-patternPor que proibido
1Banner explicando bug em vez de corrigirA tela deve mostrar dado, não desculpa
2Gambiarra como solução finalQuando algo não funciona, a saída é escalar o problema, nunca contorná-lo
3Hardcode de regra que admin deveria editarViola o Princípio 7
4Trap de contagem em pricing (medidor por entidade)Vetor de ódio universal em produto vendido
5Falha silenciosa de entrada e saída assíncronaDestrói a confiança no sistema sem deixar rastro
6Exclusão automática e silenciosa de dados sem avisoPerda irreversível decidida pelo sistema, não pelo dono do dado
7Pular a inspeção visual em trabalho com interfaceHumanos têm olhos, e quem abrir primeiro vai enxergar o defeito
8Economia de etapa do processo “porque o caso é simples”O retrabalho custa de 2 a 5 vezes a etapa pulada
9Spec sem TDD, inspeção visual ou QA conforme a naturezaValidação multi-modal é BLOCO-BASE
10Notificar usuário interno por canal externo (mensageiro, e-mail)Interno se notifica dentro do próprio sistema
11Compartilhar banco, autenticação ou serviço com estado entre projetosIsolamento absoluto entre projetos
12Documento técnico sem gatilho de obrigatoriedade explícitoPrincípio 3 do manifesto
13Marcar entrega concluída sem que o papel alcance e use a peçaPronto é benefício recebido, não código verde
14Trava que confere uma lista curada em vez de derivar o que existeA lista envelhece em silêncio e a trava segue passando verde

Voto modular

Quem adota MDS aceita que:

Toda decisão de produto, arquitetura, especificação ou implementação será documentada em blocos. Cada bloco terá categoria explícita (BASE/PLUGIN/STACK). Cada bloco terá interface clara com os adjacentes. Nenhum bloco será omitido silenciosamente. Toda omissão será declarada e justificada. Tudo o que pode ser configurado por admin será configurado por admin. Tudo o que pode ser automatizado será automatizado. Tudo o que pode ser progressivo será progressivo. O sistema trabalha pra mim, não eu pro sistema.

Wladimir Dionísio Júnior · Modulareasy · 2026