CANON — Modular Development Style (MDS)
Índice vivo único de tudo que está cravado sobre o MDS. Toda nova decisão adiciona linha aqui.
1. Identidade
| Campo | Valor |
|---|---|
| Nome | Modular Development Style (MDS) |
| Autor | Wladimir Dionísio Júnior |
| Vendor | Modulareasy |
| Origem | Sessão 7 ModularHub (2026-05-26) — evolução de discussão sobre statement universal de metodologia |
| Status | Cravamento inicial 2026-05-26 |
2. Glossário canônico
| Termo | Definição |
|---|---|
| Bloco | Unidade de planejamento, especificação ou implementação com responsabilidade clara e interface explícita |
| BLOCO-BASE | Bloco obrigatório em qualquer projeto, qualquer porte. Sem ele o projeto não é descrito. |
| BLOCO-PLUGIN | Bloco condicional — obrigatório SE o gatilho dispara. Caso contrário, N/A — [motivo] formal. |
| BLOCO-STACK | Bloco incremental — opcional, aplicável a projetos grandes/críticos/multi-módulo. Omissão livre. |
| Gatilho | Critério binário que ativa ou não um BLOCO-PLUGIN. Sempre formato pergunta S/N. |
N/A justificado | Declaração formal de uma linha indicando motivo da omissão de um PLUGIN. Obrigatório. |
| Instância | Aplicação concreta do template MDS em um projeto específico |
| Template | Conjunto canônico dos 75 campos divididos em 15 blocos macro (0 + A-N) |
| Bloco 0 | Elicitação e Discovery — precede toda especificação. Garante que o problema foi entendido antes de descrever a solução. |
| Bloco N | Feedback Loop Pós-Deploy — fecha o ciclo. Observação em produção retroalimenta a especificação. |
| Tier | Não usado em MDS (contraste com fractal de artefato — abandonado). MDS usa categoria de bloco, não tier de documento. |
3. Os 3 tipos de bloco — definição canônica
3.1 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. N/A é proibido.
Exemplos: nome do sistema, problema que resolve, atores principais, glossário, RFs principais, RNF de performance e segurança, estratégia de testes declarada.
3.2 BLOCO-PLUGIN 🟨
Obrigatório condicional. Tem gatilho binário S/N documentado. Se gatilho = S → preenchimento obrigatório. Se gatilho = N → declaração N/A — [motivo em 1 linha] é obrigatória. Omissão silenciosa é defeito.
Exemplos: interfaces de usuário (gatilho: “há humano olhando tela?”), modelo de domínio (gatilho: “há persistência?”), interfaces inter-módulo (gatilho: “≥2 módulos?”), compliance regulatório (gatilho: “LGPD/HIPAA/PCI aplica?“).
3.3 BLOCO-STACK 🟩
Incremental. Aplicável quando o projeto cresce em porte, criticidade ou complexidade. Omissão é livre, sem necessidade de justificativa formal.
Exemplos: bounded contexts (DDD), event catalog (pub/sub), runbooks operacionais, capacity planning, plano de descomissionamento de legacy.
4. Cores e ícones canônicos
| Tipo | Ícone | Cor hex | Uso |
|---|---|---|---|
| BLOCO-BASE | 🟦 | #1E40AF (azul sólido) | “fundação que sustenta” |
| BLOCO-PLUGIN | 🟨 | #D97706 (âmbar/amarelo) | “encaixa quando precisa” |
| BLOCO-STACK | 🟩 | #059669 (verde) | “empilha quando cresce” |
5. Princípios (do MANIFESTO)
Os 7 princípios em Manifesto são lei:
- Blocos que se encaixam, não monolitos que se quebram
- Universal nos conceitos, escalável no artefato
- Obrigatoriedade declarada, nunca presumida
- Gatilhos mecânicos, não julgamento subjetivo
- Sistema trabalha pra você, não você pro sistema
- Cadastro progressivo, nunca bloqueante
- Tudo é entitlement, nada é hardcoded
6. Os 15 blocos macro
| ID | Nome | Aplicabilidade |
|---|---|---|
| 0 | Elicitação e Discovery | universal (pré-spec) |
| A | Identidade e Contexto | universal |
| B | Atores e Jornadas | universal |
| C | Requisitos Funcionais | universal |
| D | Requisitos Não-Funcionais | universal (10 sub-categorias) |
| E | Modelo de Domínio | quando há persistência |
| F | Interfaces (UI + sistema↔sistema) | universal (variantes) |
| G | Arquitetura e Stack | universal |
| H | Specs por Requisito | universal |
| I | Validação Multi-Modal | universal |
| J | Entrega e Evolução | universal |
| K | Operação | quando vai pra produção |
| L | Entitlement e Configurabilidade | multi-tenant Modulareasy-opinionated |
| M | Automação e IA-Gen | Modulareasy-opinionated (§29) |
| N | Feedback Loop Pós-Deploy | quando em produção com usuários reais |
Detalhes em Template Completo.
7. Anti-patterns (do MANIFESTO §13)
12 anti-patterns proibidos em projeto MDS. Lista canônica no MANIFESTO. Aplicação automática via skills Modulareasy (fix-not-banner, anti-gambiarra-escalada, admin-editability-first, ui-smoke-test, pdf-smoke-test, project-isolation, etc).
8. Posicionamento competitivo
| Padrão de mercado | O que MDS preserva | O que MDS adiciona |
|---|---|---|
| IEEE 830 / ISO 29148 (DRS) | 10 seções estruturais | Classificação de obrigatoriedade 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 |
| PMI PMBOK | Disciplina de fases | Substitui fases por blocos (mais granular, mais composável) |
9. Relação com APEX CORE
MDS e APEX CORE são metodologias proprietárias independentes da Modulareasy, com escopos complementares:
| Aspecto | APEX CORE | MDS |
|---|---|---|
| Domínio | Gestão de pessoas e performance | Planejamento e construção de software |
| Atores principais | Coordenador, Colaborador, Auditor | Stakeholder, Dev, Agent, QA |
| Artefato central | Ritos canônicos (PED/EID/ESD/EAD) | Template de blocos (BASE/PLUGIN/STACK) |
| Status | Premium / vendido como módulo opcional | Open / publicado como metodologia aberta |
| Site | metodologia-apexcore.lovable.app | modulareasy.com/metodologias/MDS |
Não há sobreposição. APEX gerencia humanos que constroem software. MDS define como o software é especificado e construído.
10. Roadmap de evolução
Cravamento inicial (2026-05-26)
- ✅ Manifesto 7 princípios
- ✅ 3 tipos de bloco (BASE/PLUGIN/STACK) + nomenclatura canônica
- ✅ Template 15 blocos macro / 75 campos (incluindo Bloco 0 Elicitação e Bloco N Feedback Loop adicionados em 2026-05-27)
- ✅ Mini-projeto com pasta canônica
- ⏸️ Site público (estrutura HTML em
site/, deploy pendente)
Próximas evoluções (deferred)
- Skill
methodology-universal-modulareasy(model-invoked) - Atualização das skills
drs-template/prd-template/agent-spec-templatereferenciando MDS como mãe - Validator agent que checa instância MDS (lê doc, lista campos faltantes/N/A não-declarados)
- Tradução EN do site (mercado internacional)
- Aplicação retroativa em projetos vivos (OpHub V1, ModularCRM, ModularFlow) — auditoria de completude