Skip to content
nxtinno

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.

From product intent to operable architectureProduct intentgoals · constraintsDomain boundariesservices · ownershipAPIs & eventscontractsData ownershipsources of truthDeploymentcloud · KubernetesOperationsobservability
Diagram summary: product intent is decomposed into domain boundaries; boundaries define APIs and events; data ownership follows the boundaries; deployment and operations complete the loop so the architecture stays grounded in delivery.

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.