Thousands
API Endpoints (vs. WooCommerce's Few Hundred)
3 Layers
Storefront · Admin · Connect
1 Common
Model & Field Mappings
5 Protocols
REST · SOAP · GraphQL · EDI · File
MACH
Microservices · API · Cloud · Headless
What is Composable Architecture in Clarity eCommerce?
The Composable Architecture in the Clarity eCommerce platform is the layered, modular design that lets every part of the platform (storefront UI, Admin Portal, integration hub, persistence layer, ERP connector) be developed, deployed, and replaced independently while still operating as one coherent system. At its center is the
Common Model
: the shared schema of Accounts, Users, Products, Orders, Invoices, Inventory, Prices, and Addresses that every layer reads from and writes to through shared field mappings. Around that spine, three top-level modules (
Storefront
,
Admin Portal
, and
Clarity Connect
) cooperate through the same thousands-of-endpoints API. Below those, the persistence layer caches and logs every event, the EKDB external key database preserves identifiers from external systems, and multi-protocol connectors speak REST, SOAP, GraphQL, EDI, and file-based protocols to whatever your ERP, WMS, PIM, CRM, or trading partner exposes.
This layered model is what Clarity Ventures means by the
rolling chassis
. In other words, a fully functioning rolling chassis that could go down the assembly line and have any combination of body and interior installed. The composable architecture is the chassis (the frame, the drivetrain, the wheels) that lets you bolt on any storefront UI, any ERP, any marketplace channel, any analytics tool, and rebuild any one of those without taking the rest off the road. The Common Model is the frame. Multi-protocol connectors are the suspension. The persistence layer is the brake system that never lets data get lost when something goes wrong upstream.
Composable to us, means extensible, upgradeable and can grow with your organization. Composable Architecture is the foundation under every other capability in the platform.
Headless Commerce
rides on it: the storefront UI is one of the layers you can swap out.
API-First
is the access pattern that exposes every layer.
Inventory Sync
is the persistence-layer-plus-connectors story applied to one specific data type. The Common Model and the modular swap-out pattern are why customers can run on the platform for a decade without re-platforming. You upgrade the layer that needs upgrading and leave the rest in place.
The problem: monolithic platforms force you to re-buy the whole stack to change any one piece.
Most eCommerce platforms are welded together: storefront UI, catalog, checkout, admin, integration logic, and database all stitched into one indivisible app. Need to swap a storefront UI? You re-platform. Need to change ERPs? You re-platform. Need to add a marketplace channel? Custom middleware on the side, drifting away from the core every quarter. Composable Architecture exists because the alternative is paying for a re-platform every five years to make a change that should have taken a sprint.
Step-by-step composition pattern
1
Start with the Common Model as the data spine
The Common Model is the shared object schema that every layer reads from and writes to: Accounts, Users, Products, Orders, Invoices, Inventory, Prices, Addresses. Storefront, Admin Portal, and Connect all bind to it through shared field mappings, so a price changed in the ERP appears immediately to every buyer on every channel.
2
Stand up Storefront + Admin Portal on the rolling chassis
Deploy the OOTB Clarity storefront and Admin Portal so the platform is selling and being administered on day one. Both layers are themselves swappable: keep OOTB, build a custom headless UI, or run hybrid with embeddable components. The Common Model underneath stays constant.
3
Attach Clarity Connect for ERP and external-system integration
Clarity Connect is the integration hub. It handles REST, SOAP, GraphQL, EDI, and file-based protocols natively, so whatever your ERP, WMS, PIM, CRM, or marketplace exposes, Connect can talk to it without bespoke middleware. Custom Workflows and Custom Entities extend it where standard isn't enough.
4
Wire field mappings between the Common Model and your ERP
Connect uses Common Model Workflows with declarative field mappings to translate between Clarity's schema and your ERP's. Map the ERP customer ID, contract pricing tier, credit limit, address book, and tax codes once. Every order, customer, and invoice flows through that mapping bi-directionally.
5
Enable EKDB to preserve external relationships and prevent duplicates
The EKDB (External Key Database) preserves the identifier from every external system Clarity touches, so the SYSPRO customer ID, the NetSuite item key, the Salesforce contact GUID, and the Clarity Account ID all resolve to the same logical record. EKDB is how composable Clarity avoids the duplicate-customer / duplicate-product mess that kills most multi-system commerce stacks.
6
Turn on the persistence layer for caching, replay, and compliance
The persistence layer caches every event flowing through Connect and logs the full payload. If the ERP is offline, requests queue and replay automatically when it comes back. For compliance, every event is auditable: what was sent, when, by whom, with what response. HIPAA, PCI, and SOC 2 audits get clean evidence. Job Queue and Priority Queue, Batches, and Swagger UI give operators full control.
7
Swap any layer without re-platforming
Because every module binds to the Common Model and talks through the API, replacing one layer doesn't break the others. Swap the storefront UI from OOTB to a custom Next.js app. Replace the ERP connector when you migrate from one ERP to another. Add a new marketplace channel. The Common Model is the constant. Everything around it is composable.
Benefits & business impact: what a real composable stack delivers.
Composable Architecture done right doesn't just clean up your data model. It changes the economics of every future change. No more re-platforms to swap a UI. No more middleware projects to add a channel. No more duplicate-customer cleanup sprints. The platform bends to what you need to do next, on the timeline you need to do it.
No more re-platforms to change one layer
Swap the storefront UI from OOTB to custom React without touching Admin or Connect. Change ERPs without touching the storefront. Add a marketplace channel without rebuilding the catalog. The Common Model is the constant. The layers around it are independently replaceable.
Faster integration delivery
One hub speaking REST, SOAP, GraphQL, EDI, and file means every new external system is a configuration project, not a custom middleware project. Connect's Common Model Workflows and field mappings turn integration timelines from quarters into sprints.
Audit-grade compliance evidence by default
The persistence layer logs every event with full payload, timestamp, identity, and response. HIPAA, PCI, and SOC 2 auditors get evidence pulled from one log, not reconstructed across systems. Add the Clarity HIPAA Module for BAA-eligible deployments and PHI-isolated topology.
Resilience against upstream outages
If the ERP, PIM, or WMS is offline for an hour, requests queue in the persistence layer and replay automatically when service comes back. Customers don't see failure during back-end maintenance windows. The storefront keeps selling. The integrations catch up.
No duplicate customers, products, or orders
EKDB preserves every external identifier alongside the Clarity-native one. The SYSPRO customer, the Salesforce contact, the marketplace seller record, and the Clarity Account all resolve to one logical customer. The data warehouse stops being a forensics project.
Future-proof against any stack decision
React today, Next.js tomorrow, a Swift-native iOS app in parallel. SAP today, NetSuite in three years. A new marketplace in Q4. Composable Architecture absorbs every one of those decisions without forcing a rip-and-replace. The Common Model, the API, and Clarity Connect stay constant while the business evolves.
The platform pays dividends across every stakeholder group. CTOs and architects get component boundaries that match how they think about systems. Development teams ship custom layers against a stable, fully-documented API of thousands of endpoints. Integration teams consolidate every external connection into one hub instead of running parallel middleware tools. Compliance and security teams pull HIPAA, PCI, and SOC 2 evidence from one log. Finance and operations see every transaction reconcile to the ERP customer master through Clarity Connect. Over 1,600+ B2B clients, including Disney and Merck, run on the same chassis. CEOs get a platform that doesn't cost a re-platform every five years to keep current with the business.
Frequently asked questions
What is Composable Architecture in Clarity eCommerce?
Composable Architecture is the layered, modular design of the Clarity eCommerce Framework. Storefront, Admin Portal, and Clarity Connect integration hub all bind to a single Common Model with shared field mappings, supported by multi-protocol connectors (REST / SOAP / GraphQL / EDI / file), an EKDB external key database, and a persistence layer that caches and replays every event. Each layer is independently swappable: replace the storefront UI without touching the integration hub, change ERPs without touching the storefront, add a new channel without rebuilding the data model. The platform exposes thousands of API endpoints across these layers, so every capability is reachable programmatically.
How does Composable Architecture differ from a monolithic eCommerce platform?
A monolithic platform welds storefront, catalog, checkout, admin, and integration into one indivisible application. Replacing any piece means replacing the whole thing, which is why re-platforms typically happen every five years. Composable Architecture separates concerns: the Storefront is one module, the Admin Portal another, Clarity Connect another, the data layer another, the persistence layer another. Each binds to the Common Model and talks through the API. You can upgrade the storefront UI to a custom Next.js front-end while the same Admin Portal and Connect stack keep running underneath.
How is Clarity Composable Architecture aligned with MACH?
MACH stands for Microservices, API-first, Cloud-native, Headless. Clarity is built on all four. The platform decomposes into independently deployable services. It was built API-first / headless-first from the ground up with thousands of endpoints. It runs cloud-native on standard infrastructure (Azure, AWS, GCP, on-prem) with horizontally scalable workers and queues. And it is fully headless capable, with OOTB UI as an option rather than a requirement. Composable Architecture is the umbrella. MACH is the set of principles it follows.
What protocols do Clarity Connect's multi-protocol connectors support?
Clarity Connect speaks REST, SOAP, GraphQL, EDI, and file-based protocols out of the box, plus database connectors for direct SQL / NoSQL targets. That coverage is intentional: legacy ERPs frequently expose SOAP only. Modern SaaS systems expose REST or GraphQL. Trading-partner integration runs over EDI. Some inventory feeds arrive as scheduled CSV / XML drops. One integration hub covers every protocol, so you don't end up running three middleware tools in parallel.
What does the persistence layer actually do?
The persistence layer caches every event flowing through Clarity Connect and logs the full payload before, during, and after each integration call. That delivers three things: performance, because repeated reads hit the cache rather than the source system. Resilience, because if the ERP is offline the request queues and replays automatically when it comes back, and compliance, because every event (what was sent, when, by whom, with what response) is auditable. HIPAA, PCI, and SOC 2 audits use the persistence layer's log as primary evidence. Job Queue and Priority Queue (Hangfire-powered), Batches, and Swagger UI give operators full visibility.
What is EKDB and why does it matter for composable systems?
EKDB (External Key Database) preserves the identifiers from every external system Clarity touches alongside the Clarity-native identifier for the same logical record. The SYSPRO customer ID, the NetSuite item key, the Salesforce contact GUID, and the Clarity Account ID all resolve to one logical customer or product. That is how composable Clarity prevents the duplicate-customer / duplicate-product / duplicate-order problem that kills most multi-system commerce stacks. The relationships across systems are preserved, not approximated by name matching.
Is Clarity Composable Architecture HIPAA-compliant?
Yes. The Clarity HIPAA Module wraps the standard Composable Architecture with the controls HIPAA requires: encryption in transit and at rest, role-based access (PHI separated from non-PHI by Role), audit logging via the persistence layer, BAA-eligible deployment topologies, Wireguard turn-key connectivity for secure ERP and EHR integration, and a customizable backend database (Postgres / SQL Server) so customers in regulated industries can host on infrastructure they control. The composable model is what makes HIPAA practical, because you can isolate PHI-handling modules from the rest of the platform.
See it with your stack
Tour the composable architecture: Common Model, multi-protocol connectors, persistence-layer replay, and a live ERP sync.
Schedule a 30-minute walkthrough and we'll show the composable stack in action: Storefront and Admin Portal selling from the OOTB chassis, Clarity Connect running multi-protocol connectors against a sandbox ERP, the EKDB resolving identifiers, the persistence layer queuing during a simulated outage and replaying when service returns, and the same API powering all of it. Bring your ERP, CMS, and channel mix.
ThousandsAPI Endpoints
1,600+B2B Clients
25+ERPs Synced
