Multi-brand commerce: reuse without erasing differences

The hard part of a multi-brand platform is not changing a logo and color palette. It is sharing product, cart, checkout, and order capabilities while preserving differences in content, visual identity, promotions, channels, and release cadence.

Layer the system instead of copying it

Brand application layer
  ├─ design tokens / content configuration
  ├─ brand capability matrix
  └─ page composition and controlled slots

Shared domain layer
  ├─ catalog / inventory / price
  ├─ cart / promotion / checkout / order
  └─ authentication / customer / address

Channel adapter layer
  ├─ Web
  └─ WeChat Mini Program

Share domain models and API clients. Inject brand differences through design tokens, configuration, and explicit extension points instead of spreading if (brand === 'x') throughout core flows.

When a fork is healthier

If a difference changes the domain workflow, evolves under an independent team, or requires a separate release cadence, forcing it into configuration creates a condition maze. An independent application can be the better boundary while shared packages retain stable public APIs and contract tests.

Mini Program capabilities

Domain logic may be reused, but UI, lifecycle, package limits, permissions, and platform APIs are different. Login authorization and subscription messages can be services or composables responsible for:

• capability and platform-version detection;
• permission state, user-trigger timing, and result-code mapping;
• explanation, settings entry, and degradation after denial;
• consistent logs with brand, platform, and release dimensions.

Release isolation

Put brand differences into an explicit capability matrix and build/runtime configuration. Contract tests protect core journeys. High-risk changes can be canaried by brand, and errors and performance metrics should include brand, channel, and release dimensions.

Acceptance should cover PLP → PDP → cart → checkout → order, authentication expiry, inventory and price changes, promotion invalidation, accessibility of content slots, Mini Program package constraints, and proof that a change for one brand does not alter another brand’s artifact or runtime configuration.