Software Scaffolding Engines with Intent-Driven Engineering
- Mark Kendall
- 18 hours ago
- 3 min read
Scaffolding Engines with Intent-Driven Engineering
A Complete Guide to Building Repeatable Microservice Generation Across Any Technology Stack
Introduction
Most engineering teams don’t struggle to build one good service.
They struggle to build twenty consistent ones.
What typically happens:
The first service is well-architected
The next few drift slightly
By service ten, patterns diverge
By service twenty, the system becomes inconsistent
This document defines a practical solution:
Build the architecture once. Reuse it forever.
Using Intent-Driven Engineering, you will create a scaffolding engine that:
Reuses proven architectures
Generates new microservices on demand
Maintains consistency across teams and stacks
This is not a developer-level tool.This is an architect-level system for creating platforms.
What Is a Scaffolding Engine?
A scaffolding engine is not a code generator.
It is:
A system that clones a validated architecture and injects new behavior based on intent
Instead of writing services manually, you:
Define the service using intent
Apply it to a base architecture
Generate a new microservice
Core Mental Model
Architecture (fixed)
+
Intent (variable)
=
Generated Microservice
System Structure
/api-base/
fastapi/
springboot/
dotnet/
/intents/
fastapi/
springboot/
/output/
<generated services>
Step 1 — Identify a Proven Base Architecture
You must start with something that already works.
Sources:
Open-source repositories
Internal production services
Reference implementations (e.g., TMF systems)
A Good Base Must Include:
Clear separation of concerns (controller/service/data)
Logging and observability
Error handling patterns
Configuration management
Clean, runnable structure
Do not skip this step. Everything depends on this.
Step 2 — Validate and Normalize the Base
Before using it:
Run It
mvn spring-boot:run
# OR
uvicorn main:app --reload
Ensure:
It compiles
It runs
Endpoints respond
Normalize It
Standardize package/module naming
Remove irrelevant domain logic
Ensure consistent structure
Identify Injection Points
You must know:
Layer | Purpose |
Controller / Routes | API entry |
Service | Business logic |
Model / DTO | Data contract |
Step 3 — Freeze the Architecture
/api-base/<technology>/
Rules:
Immutable during generation
Versioned if necessary
Used as the canonical template
Step 4 — Define Intent
Intent describes what to build, not how.
It includes:
Service name
Base path
Resources/endpoints
Request/response models
Behavior
Example Intent (Conceptual)
Service: Geocoding
Endpoint: POST /v1/locations/geocode
Input: latitude, longitude
Output: address, city, country
Step 5 — Apply Intent to Architecture
Using Claude Code or similar:
Engine Workflow
Clone base:
/api-base/<tech> → /output/<service>
Inject behavior:
Add routes/controllers
Create models/DTOs
Implement service logic
Wire components:
Register endpoints
Connect service layers
Step 6 — Preserve the Architecture
Modify ONLY:
Controllers / Routes
Models / DTOs
Service logic
NEVER Modify:
Logging
Middleware
Security
Configuration
Core architecture
Step 7 — Generate and Run
cd output/<service>
FastAPI
uvicorn main:app --reload
Spring Boot
mvn spring-boot:run
Step 8 — Repeat at Scale
cp geocoding.md customer.md
cp geocoding.md tms.md
Edit intent → apply → generate → run
Open Source vs Internal Base
Open Source
Pros:
Fast start
Proven design
Cons:
Needs normalization
Not aligned with internal standards
Internal Base (Preferred)
Pros:
Fully controlled
Consistent across teams
Cons:
Requires initial investment
Key Insight
You are not generating code.You are instantiating architecture with intent.
==========================================
🔥 FULL WORKED EXAMPLE — SPRING BOOT
==========================================
Step 1 — Select an Open Source Base
Example:
Step 2 — Clone It
git clone https://github.com/spring-projects/spring-petclinic.git
cd spring-petclinic
Step 3 — Run It
./mvnw spring-boot:run
Open:
Confirm:
App runs
No errors
Structure is valid
Step 4 — Create Your Base
mkdir -p ../api-base/springboot
cp -R . ../api-base/springboot
Step 5 — Normalize
Rename package (recommended)
From:
org.springframework.samples.petclinic
To:
com.company.base
Identify Layers
Layer | Location |
Controller | /web/ |
Service | /service/ |
Repository | /repository/ |
Model | /model/ |
Step 6 — Freeze Base
/api-base/springboot/
Step 7 — Create Intent
/intents/springboot/geocoding.md
Example Intent
You are a senior Java architect.
SOURCE:
./api-base/springboot/
TARGET:
./output/geocoding-service/
SERVICE:
GeocodingService
BASE PATH:
/api/v1/locations
ENDPOINT:
POST /geocode
REQUEST:
latitude: double
longitude: double
RESPONSE:
address: String
city: String
state: String
country: String
postalCode: String
INSTRUCTIONS:
- Clone base project
- Create controller
- Create DTOs
- Create service class
- Wire endpoint
- Preserve architecture
Step 8 — Apply Intent
Apply this intent to my workspace
Use ./api-base/springboot
Output to ./output/geocoding-service
Step 9 — Run Generated Service
cd output/geocoding-service
./mvnw spring-boot:run
Test:
POST /api/v1/locations/geocode
Step 10 — Result
You now have:
A new Spring Boot microservice
Built from a proven architecture
Generated from intent
Repeat
cp geocoding.md customer-api.md
Change:
SERVICE: CustomerService
BASE PATH: /api/v1/customers
Run again → new service
Final Architecture
/api-base/
springboot/
/intents/
springboot/
/output/
geocoding-service/
customer-service/
Final Conclusion
This system transforms development from:
Writing services manually
To:
Instantiating systems from architecture
Final Thought
The hardest part is choosing the right base.
Once that is solved:
Everything else becomes repeatable.
Comments