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
  • Configurable: strict
  • Disabled: none (no generated guardrails tests)

• Hexagonal / Standard (Layered) layouts (profile-driven)

  • Default: standard
  • Selectable: hexagonal

• 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.x

• 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, introduces implicit behavior, 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

  • reduce implicit assumptions
  • make architectural decisions visible earlier

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 expand the contract surface.
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 💙✨