---
id: ADR-COM-CAT-020
title: Catalog Product Records Across Commerce Facets
product_area: commerce
module: catalog
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Catalog and Merchandise share one product concept inside Commerce while owning its presentation and goods
  facets separately.
constrains:
  - DOM-COM-CAT-003
  - SVC-COM-CAT-catalog
  - SVC-COM-CAT-merchandise
  - RESP-COM
origin: none (the module layout of the macroservice)
alternatives:
  - option: Combine both facets into one source module
    why_not: The goods participant has its own purchase and inventory responsibilities in the existing architecture.
consequences:
  - Both service contracts identify the shared product object and describe the facets they hold.
  - Listing validation reads goods delivery rather than storing another delivery setting.
  - The facet split introduces no macroservice network boundary.
supersedes: []
evidence:
  - >-
    services-commerce at c8b66a98: modules/catalog/services/persistence/product-listings.ts (readDeliveries);
    modules/merchandise/db/merchandise.table.ts.
---

# Catalog Product Records Across Commerce Facets

## Context

Planning groups the product as one broad noun, while the service module boundary follows presentation versus purchase-participant responsibilities.

## Decision

Catalog and Merchandise share one product concept inside Commerce while owning its presentation and goods facets separately.

## Alternatives Considered

Combine both facets into one source module. The goods participant has its own purchase and inventory responsibilities in the existing architecture.

## Consequences

Both service contracts identify the shared product object and describe the facets they hold. Listing validation reads goods delivery rather than storing another delivery setting. The facet split introduces no macroservice network boundary.