Pular para o conteúdo principal

01. MDS · Modular Development Style

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

MDS é a metodologia canônica Modulareasy para planejar, especificar e construir software em qualquer porte — do script de 30 linhas ao SaaS multi-tenant de 12 módulos. Template único, 15 blocos macro (0 + A–N), 75 campos, classificação explícita de obrigatoriedade. Cobre do discovery (Bloco 0) ao feedback loop pós-deploy (Bloco N).

Metodologia tradicional ou é prescritiva demais, ou vaga demais.

Projetos de software variam de 30 linhas de webhook a 12 módulos multi-tenant white-label. Aplicar IEEE 830 num webhook vira ritual cargo-cult; aplicar Lean Startup em produto regulado é insuficiente.

MDS resolve com quatro premissas:

  1. Template único — mesmas categorias, mesmo vocabulário, em qualquer porte.
  2. 3 tipos de bloco (BASE / PLUGIN / STACK) que diferenciam o que SEMPRE existe, o que existe SE condição dispara, e o que existe APENAS em projetos grandes.
  3. Gatilhos mecânicos — quando um BLOCO-PLUGIN ativa, é decisão binária (não julgamento).
  4. "N/A justificado" barato — preferível omitir nada a esconder.

Classifique a obrigatoriedade. Nunca subtraia vocabulário.

Cada um dos 75 campos do template MDS tem uma categoria explícita. Essa é a inovação central da metodologia em relação aos padrões existentes (IEEE 830, DDD, ADR).

🟦 🟦 BASE

BLOCO-BASE

Obrigatório universal. Existe em qualquer projeto, do script de 30 linhas ao SaaS multi-tenant. Quando ausente, o projeto não é descrevível pelo template.

Quando preenche
sempre, qualquer projeto
Quando omite
nunca — N/A não aceito

Exemplos: Nome do sistema, problema que resolve, atores principais, glossário, RFs principais, RNF de performance e segurança, estratégia de testes declarada.

🟨 🟨 PLUGIN

BLOCO-PLUGIN

Obrigatório condicional. Tem gatilho binário S/N documentado. Se sim → preenchimento obrigatório. Se não → N/A formal. Omissão silenciosa é defeito.

Quando preenche
quando gatilho dispara
Quando omite
N/A — [motivo em 1 linha] formal

Exemplos: Interfaces de usuário (gatilho: "há humano olhando tela?"), modelo de domínio ("há persistência?"), compliance ("LGPD/HIPAA/PCI aplica?").

🟩 🟩 STACK

BLOCO-STACK

Incremental. Aplicável quando o projeto cresce em porte, criticidade ou complexidade. Omissão é livre, sem necessidade de justificativa formal.

Quando preenche
projetos grandes / críticos / multi-módulo
Quando omite
omissão livre, sem justificativa

Exemplos: Bounded contexts (DDD), event catalog (pub/sub), runbooks operacionais, capacity planning, plano de descomissionamento de legacy.

O manifesto. Inviolável.

Toda decisão de design da metodologia deriva destes sete princípios. Toda instância MDS de um projeto precisa respeitá-los.

01

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

Todo sistema é composição de blocos com responsabilidades claras e interfaces explícitas. Monolitos são proibidos como princípio: até a spec de um endpoint solitário é um BLOCO-BASE.

02

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.

03

Obrigatoriedade declarada, nunca presumida

Três categorias — BASE, PLUGIN, STACK. Cada bloco carrega sua categoria explícita. Quando um PLUGIN não dispara, o documento declara N/A formalmente em uma linha.

04

Gatilhos mecânicos, não julgamento subjetivo

Cada PLUGIN tem gatilho binário: "tem persistência? S/N". Sim → bloco obrigatório. Não → N/A. Decisão não passa por julgamento estético.

05

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

Todo bloco responde: o que automatiza? que evento dispara? onde cabe "Gerar com IA"? que dados já existem que ele pode consumir? Bloco que só captura sem retornar valor é defeito.

06

Cadastro progressivo, nunca bloqueante

Em todo bloco com campos editáveis, somente o identificador é obrigatório. Sistema USA quando preenchido; AUSÊNCIA nunca bloqueia operação.

07

Tudo é entitlement, nada é hardcoded

Toda decisão de comportamento, regra de negócio, limite, preço, feature flag tem que ser configurável em runtime via UI de admin. Hardcode que exige deploy é defeito de processo.

15 blocos. 75 campos. Mesmo vocabulário em qualquer porte.

O template MDS é a régua canônica. Cada projeto Modulareasy renderiza este template com BASE preenchido, PLUGIN respondidos S/N, STACK conforme aplicável.

0 Elicitação e Discovery universal (pré-spec) 6 campos
A Identidade e Contexto universal 7 campos
B Atores e Jornadas universal 5 campos
C Requisitos Funcionais universal 5 campos
D Requisitos Não-Funcionais universal 10 campos
E Modelo de Domínio quando há persistência 5 campos
F Interfaces universal (variantes) 6 campos
G Arquitetura e Stack universal 7 campos
H Specs por Requisito universal 3 campos
I Validação Multi-Modal universal 9 campos
J Entrega e Evolução universal 5 campos
K Operação quando vai pra produção 5 campos
L Entitlement e Configurabilidade multi-tenant opinionated 4 campos
M Automação e IA-Gen Modulareasy-opinionated 4 campos
N Feedback Loop Pós-Deploy em produção com usuários reais 7 campos

O que MDS preserva e o que adiciona.

MDS não substitui os padrões consagrados. Adiciona uma camada de classificação que estava faltando para projetos de porte variável.

Padrão de mercadoO que MDS preservaO que MDS adiciona
IEEE 830 / ISO 29148 10 seções estruturais de DRS Classificação BASE / PLUGIN / STACK
DDD (Eric Evans) Bounded contexts, ubiquitous language, aggregates Posiciona DDD como BLOCO-STACK (incremental, não BASE)
ADR (Michael Nygard) Template ADR formal Encadeia ADR como artefato do BLOCO-G2
Spec-Driven Development Spec como source of truth Tipifica spec em 3 níveis (mínima H1, estruturada H2, cross-RF H3)
Lean Startup Hipóteses + experimentos Vai além — cobre toda a cadeia, não só descoberta

Quer aplicar MDS no seu próximo projeto?

Conversamos sobre adequação, escopo e onboarding. Sem rituais comerciais.

Falar com a Modulareasy