Skip to content

System Boundaries

This document defines what belongs inside Shop3 and what should stay outside it.

Theme Responsibilities

The theme owns storefront templates, layout presentation, theme-owned CSS/JavaScript/images, visual theme settings, rendering conventions, and documented defaults or fallbacks.

Module Responsibilities

Modules own feature behaviour that can be enabled, disabled, placed, or configured independently. The theme may style or display module output, but should not absorb unrelated module logic.

OpenCart Core Responsibilities

OpenCart core owns routing, request lifecycle, core catalog, checkout, customer, order, payment, shipping, admin behaviour, model contracts, database schema, and extension systems.

The project must not modify OpenCart core files.

Integration Responsibilities

Integrations own external service communication, API credentials, vendor-specific data contracts, and payment/shipping/ERP/CRM-specific behaviour.

The theme can expose visual hooks for integrations, but should not implement external business systems directly.

Layout Responsibilities

Layout architecture owns page containers, header/footer/navigation structure, responsive regions, and canonical placement rules for theme-owned blocks.

OpenCart layouts and modules remain the canonical mechanism for module placement unless a separate architecture PR defines another approach.

Settings Responsibilities

Theme settings own visual and theme behaviour configuration. They should be namespaced, sectioned, validated, and cached. Settings must not become a catch-all for unrelated business logic.

What Must Not Go Into The Theme

Do not put these into the theme:

  • business ERP logic;
  • payment processing logic;
  • shipping carrier business rules;
  • unrelated marketplace hacks;
  • random vendor overrides;
  • hardcoded customer-specific behaviour;
  • direct OpenCart core patches;
  • broad third-party module rewrites;
  • hidden data migrations unrelated to the theme.

If a request crosses these boundaries, document it in PR Notes and route it to the right system or architecture review.