ADR-0015: Microservices Archetypes Deferred to V1
Date: 2026-06-10
Context
Enterprise architectures often involve multiple deployable services (microservices, polyrepo monorepos, event-driven systems). An Archetype that generates such a system is fundamentally different from one that generates a single deployable app.
Building microservice Archetype support for MVP would substantially expand scope: multi-app orchestration, service discovery wiring, cross-service Seam coordination, deployment manifests for a service mesh, etc.
Decision
MVP Archetypes are monolith-shaped (one deployable app, possibly with backend + frontend in the same generation). The Archetype Spec schema is designed to accommodate microservices in the future without breaking changes, but the Composer does not implement multi-app generation until v1.
Rationale
- Single-app generation is well-defined; multi-app introduces orchestration concerns that distract from the core thesis.
- The schema design includes optional fields (
service_topology, etc.) reserved for future use, so adding microservice support is non-breaking. - Most enterprise pain points addressed by Almathal (compliance, provenance, trust) apply equally to monolith and microservice apps; proving the architecture works for monoliths first is sufficient validation.
- A v1 microservice Archetype is feasible after MVP foundations are solid.
Consequences
- The MVP can’t generate, e.g., a full microservices e-commerce platform. Customers wanting that wait for v1 or use the fallback path.
- Schema fields for microservice topology are documented as “reserved for v1.”
- The Composer is implemented with monolith-only assumptions; multi-app orchestration is a v1 work item.