Design principles

These principles guide how Evolve is built and how it is intended to be used by project teams.

Vendor independence

Evolve owns its data model and does not expose vendor APIs directly. Each domain service maps vendor-specific data into Evolve's GraphQL schema, which means you can swap or combine SAAS backends without changing the API your frontend consumes. This applies across the board: commerce engines, CMS platforms, search engines, payment providers, and PIM systems.

Composability

The platform is modular by design. You pick the domain services you need, combine them through GraphQL Federation, and add or replace services over time. Need a different CMS? Replace one subgraph. Need B2B? Add the business unit and quote services. The architecture supports any composition without requiring changes to unrelated services.

Project autonomy

Evolve is a starting point, not a constraint. Projects built on Evolve should be able to evolve freely without being limited by the platform's defaults. The framework provides shared logic that projects can use as-is, override selectively, or extend with custom modules. Your project owns its own services, configuration, and deployment, and can diverge from the defaults wherever your use case requires it.

Developer experience

The codebase is worked on by developers across different companies and experience levels. This means code should be straightforward to read, understand, and modify. Evolve favours explicit patterns over clever abstractions: services follow a consistent three-file structure, GraphQL modules have a predictable shape, and shared logic lives in well-documented packages rather than hidden behind framework magic.

Cloud-native

Services are designed as twelve-factor apps: stateless, configured through environment variables, with structured logging and graceful shutdown. This makes them portable across cloud providers (AWS, GCP, Azure) and straightforward to scale, monitor, and operate in production.

Multi-channel

The GraphQL Federation layer serves all channels through a single API: web storefronts, mobile apps, and AI agents through the Model Context Protocol. Business logic is implemented once in the domain services and shared across all channels, rather than duplicated per client.

Infrastructure as code

Everything is defined declaratively in Terraform: cloud resources, SAAS service configuration (commercetools projects, CMS content models, search indices), and deployment pipelines. A new environment, including all its dependencies, can be provisioned from a single command with no manual setup.