AxCom - Modular Headless Commerce Engine
The Narrative
Small teams building custom storefronts face a bad trade-off: adopt a heavyweight platform they don't fully need, or rebuild the same commerce plumbing - products, carts, orders, payments, auth - from scratch for every project. Most lightweight alternatives also skip the operational basics (metrics, tracing, sane deployment), which only hurts later in production.
I built a modular engine where each commerce domain is an independent module with zero cross-module imports, so teams can reason about - and extend - one area without touching the rest. Infrastructure is swappable through adapters (PostgreSQL or MongoDB, Redis caching, RabbitMQ messaging, S3/R2 storage) selected by configuration, not code changes. Observability, auth, and rate limiting are built in from day one, and the whole engine compiles to one static binary for trivial deployment.
Key Features
Seven independent domain modules
Auth, catalog, inventory, cart, orders, payments, and shipping - each with its own controller, service, and repository layers, and no cross-module imports.
Swappable infrastructure adapters
Switch between PostgreSQL and MongoDB, enable Redis caching or RabbitMQ events, via configuration alone - business logic never changes.
Security at the gateway
JWT authentication with role-based access control, rate limiting, and CORS handled centrally at the API gateway layer.
Observability out of the box
OpenTelemetry tracing, Prometheus metrics, and structured JSON logging - Grafana/Jaeger-ready without extra instrumentation work.
One-binary deployment
Compiles to a single static binary; published Docker images and a Docker Compose environment give a one-command local setup.
Real open-source governance
Full documentation site, API reference, contribution guide, security policy, and code of conduct - built for community collaboration.
Engineering
// SYSTEM_OVERVIEW
Modular monolith in Go: seven isolated domain modules behind a shared API gateway, with configuration-driven infrastructure adapters and built-in observability, compiled to a single static binary.
01_MODULE: ARCHITECTURE
AxCom follows clean architecture with strict module boundaries. Each of the seven domain modules owns its controllers, services, repositories, and models; modules never import each other, communicating only through well-defined interfaces. This keeps the codebase navigable and makes individual modules independently testable and replaceable.
02_MODULE: ADAPTER PATTERN FOR INFRASTRUCTURE
Storage, caching, messaging, and file storage sit behind adapter interfaces. The engine runs on PostgreSQL or MongoDB, with optional Redis caching, RabbitMQ event messaging, and S3/R2-compatible object storage - all chosen through environment configuration at startup rather than code changes.
03_MODULE: CI/CD & RELEASES
GitHub Actions handles the pipeline end to end: build, test, versioned releases, and automated Docker image publishing. The Docusaurus documentation site deploys to GitHub Pages, keeping API reference and guides in sync with releases.
04_MODULE: OBSERVABILITY
The engine is instrumented with OpenTelemetry for distributed tracing, exposes Prometheus metrics, and emits structured JSON logs - designed to plug into a Grafana/Jaeger stack with zero additional application code.
Results
Published as a public open-source project (Apache-2.0) with a full documentation site and API reference.
Ships as a single static binary with published Docker images and a one-command Docker Compose setup.
Observability (OpenTelemetry tracing + Prometheus metrics + structured logging) built in from day one.
Runs on either PostgreSQL or MongoDB with no code changes, thanks to configuration-driven adapters.
TODO: add adoption metrics (GitHub stars, releases published, contributors) once meaningful.