Case study
Product catalogue and configuration architecture
Defined modular catalogue, configuration, pricing, promotion, policy, and qualification flows for a complex digital commerce environment, aligned with industry-standard APIs and domain boundaries.
- Domain architecture
- APIs
- Rules
- Integration
Context
A complex digital commerce environment where products, pricing, promotions, and eligibility rules interacted in ways that had grown organically and become hard to change safely.
Challenge
Catalogue and configuration logic was entangled: a pricing change could break qualification rules, and launching a new product variant required touching several systems with unclear ownership.
Constraints
- alignment with industry-standard API specifications
- many existing consumers that could not migrate at once
- commercial rules owned by non-engineering teams
- a delivery organisation split across several vendors
Approach
- Decomposed the domain into catalogue, configuration, pricing, promotion, policy, and qualification with explicit contracts between them.
- Mapped each capability onto industry-standard API definitions so vendors and consumers had a shared vocabulary.
- Introduced a rules boundary so commercial logic could change without redeploying core services.
- Sequenced the migration so existing consumers kept working while new capabilities landed incrementally.
Architecture
Modular domain services behind standard commerce APIs, with an externalised rules capability and a staged migration path from the legacy estate.
Key decisions
- domain boundaries drawn around business capabilities, not existing systems
- industry-standard APIs as the integration contract between vendors
- rules externalised behind a policy boundary rather than embedded in services
Details are anonymised. Additional context is available under NDA.
Related expertise
Curious what AI could actually do for your business?
Bring your questions, including the ones that feel too basic. In 30 minutes we go through how you work today, pick the task with the most to gain, and sketch what testing it would involve. No pitch, no obligation.
Prefer email? hello@nxtinno.com