Help Shape the Roadmap: How Should Codegen Blueprint Evolve Next?

[bsayli]

Category: Ideas
Tags / labels: roadmap, architecture, guardrails, platform, spring-boot

💡 Help Shape the Roadmap: What Should Codegen Blueprint Evolve Next?

Thanks for being here — and for helping shape the future of Codegen Blueprint.

Today, the engine delivers a buildable, architecture-first baseline:

• Executable architecture guardrails (build-time, deterministic)
  • Default: basic
  • Opt-in: strict
  • Optional: none (disabled — no generated guardrails tests)
• Hexagonal / Standard (Layered) layouts (profile-driven)
• Generated project support: Spring Boot 3.4.x and 3.5.x
  • Default: 3.5.x (when --boot is not provided)
• Generator runtime baseline: Java 21 + Spring Boot 3.5.9
• Maven build + wrapper
• Deterministic output, continuously verified in CI

This project is not about generating more files.
It is about evolving Architecture as a Product — observable, testable, and durable over time.

🧩 Best practices should execute, not merely be documented.

---

📌 Where should Blueprint evolve next?

You can vote, comment, or propose a direction — but please keep the platform principles in mind:

Contract first. Proof before expansion.

Anything that weakens determinism, blurs boundaries, or bypasses guardrails will not be prioritized — even if it is popular.

---

🧱 Architecture & Structural Evolution

Areas that strengthen architectural clarity and drift prevention:

• Clearer and more explicit architecture contracts per layout

• Guardrails evolution (without silent behavior changes)

  • richer failure messages and remediation guidance
  • additional rule packs / strictness refinements (always explicit)

• CQRS evolution kit

  • ports, commands, queries
  • no framework lock-in
  • guardrails-aware by design

• Testing conventions aligned with architectural boundaries

  • not test frameworks, but structure-aware testing guidance

---

🔌 Delivery Surfaces (Same Core, New Entry Points)

The core engine remains unchanged. Only delivery surfaces evolve:

• REST inbound adapter (same engine, new entry point)
• Interactive onboarding / configuration (still contract-first)
• Better intent capture before generation (no hidden defaults)

New surfaces must reuse the same core contracts — not fork them.

---

🧩 Enforced Capabilities (Not Generated Code)

Cross-cutting concerns are not generated as boilerplate.
They are delivered as versioned capabilities, evaluated and governed consistently.

Examples:

• 🔐 Security capability (OAuth2 / Keycloak)
• 🔍 Observability capability (tracing / logs / metrics)
• 📡 Resilience capability (retries / policies / timeouts)
• 📘 API standards, error models, and versioning conventions

These are capabilities, not templates.
Behavior should be enforced — not copy-pasted.

---

🧰 Profile & Stack Expansion (Later, Deliberately)

Profiles increase adoption — but also surface area.
They come after the contract and proof are mature.

• Gradle profile (high demand, manageable scope)

• Kotlin profile (higher cost, higher payoff)

• Quarkus or alternative JVM stacks

  • only after guardrails maturity

---

💬 Your Voice Matters

We’d love to hear:

• What would your team adopt immediately?
• What problem hurts most after project generation?
• Which architectural capability should become guardrail-visible next?

Drop your thoughts below 👇
Be early. Shape the standard. 🧩

Let’s build Executable Architecture together 💙✨