From Products to Domains: How Modeling Works in Saleor
Modern commerce goes beyond products and orders. Learn how Saleor’s dynamic modeling lets you extend your domain and power Commerce as Code.
Very rarely do customers come to us with a domain model that fits perfectly into Saleor’s native data representation. That’s no surprise—we are a commerce engine, not a rigid template, and we don’t expect the world to bend to our design decisions. Instead, our focus is enabling our customers to build workflows that feel their own.
This is the core philosophy behind modeling: going beyond products and orders to include the entities that make your commerce domain unique.
Our emphasis on modeling is what led to changes in the Saleor Dashboard, including:
- Going from Pages to Models
- Going from Menus to Structures
- Updating the navigation accordingly
Take a clothing shop as an example. On the surface, it might only need a catalog that expresses different sizes, colors, and materials. But what if it also needs to represent brands as first-class citizens? In most platforms, you’d have to reach for an external CMS and model that data yourself. With Saleor, you can keep it all inside your commerce domain. A brand can be a model with its own bio, image, list of related products, and other details, all in the form of attributes.
Of course, storing extra data alone isn’t meaningful. In Saleor, every field carries behavior: attributes generate variants, weights drive shipping, prices connect to checkout. Custom models should work the same way—more than metadata, they become actionable once your systems use them.
In a more complex example, consider a marketplace, where a product has a single top-level page, but multiple vendors can offer it. Each Vendor Offer links a vendor to the shared product information, so customers see one product page with competing offers instead of fragmented listings. In Saleor, you can define a Vendor model with both catalog details and the technical data you need to orchestrate this flow. Then, you can act on that data in your custom-built services—whether that’s powering a vendor portal, automating fulfillment workflows, or driving analytics dashboards.
This flexibility comes with some implementation complexity—but it gives you the edge. You can bring your unique commerce flows to life instead of reshaping your business to fit a platform’s defaults.
One key characteristic of Saleor’s approach to modeling is that it’s dynamic. Unlike traditional platforms, it doesn’t require any database operations—which are intentionally prohibited by the way Saleor is built. Saleor is not a framework where you write backend code and interface with the database directly. It’s an engine that you extend.
Extensions to the commerce domain happen dynamically through the API. Every entity—brand, vendor, or something unique—is created and maintained this way. You roll out changes without backend deployments, database migrations, or tech lock-in.
The upside of this approach is that Saleor itself stays lean and stable, while your custom logic lives outside the engine. Your own models don’t risk breaking the platform, and Saleor can keep evolving without being weighed down by individual business requirements. Your domain evolves as quickly as you can define it.
And this is where modeling connects to a broader idea: Commerce as Code. If every entity and relationship in your domain can be expressed through the API, then it can also be defined declaratively in your codebase, versioned in Git, and deployed alongside your application. This philosophy is embodied in Saleor Configurator, our tool for defining and provisioning entire commerce domains through code. Modeling isn’t just about extending Saleor—it’s about treating your entire commerce domain the same way modern teams already treat infrastructure and applications: as code.