Applying Domain-Driven Design and Polymorphic Architecture to E‑commerce Product Detail Pages

Preface

This article is based on the author’s work experience of refactoring existing business using Domain‑Driven Design (DDD) and iterating requirements on a domain model.

Domain‑Driven Design (DDD)

DDD uses a domain model to express rich software functionality, enabling the software to meet real user needs and is regarded as a key to software design.

Polymorphic Implementation

In this context it refers to providing methods on the same domain model that can be invoked polymorphically.

The author built a domain model for an e‑commerce product display page to satisfy complex and changing requirements.

Domain Architecture Design

DDD splits business modules into independent domains, each focusing on its own responsibilities, which facilitates business decomposition and composition.

The product page is critical for conversion and can be broken down into domains such as product base, full product information, promotion, inventory, user, and store.

Domain splitting criteria include business meaning, organizational hierarchy, and reducing technical complexity.

Business Meaning Differentiation

Distinguishes promotion domain from price domain; price is tightly bound to the product, while promotion defines sales rules like discounts, bundles, and gifts.

Organizational Structure

Determines system architecture; store and shop are maintained by separate departments, leading to separate domains.

Reducing Implementation Complexity

Splits the product into a base domain (basic info) and a full domain (complete model) to lower technical difficulty.

Design of Relationships Between Domains

Domains inevitably need to reference each other (e.g., promotion needs product ID, inventory needs location). To preserve domain independence, a relationship network independent of business logic stores UUID‑based links between aggregate roots.

Each aggregate root receives a unique UUID; the network records pairwise UUID relationships without caring about domain specifics.

This approach lets each domain manage its own relationships while sharing a common network for lookup.

Polymorphic Handling of Domain Logic

After establishing the domain model and relationship network, complex logic is handled by exposing basic business interfaces in each domain and routing execution based on business scenarios, similar to an abstract‑factory pattern, achieving decoupled and plug‑in‑able functionality.

Concrete Cases

1. Online Product Sold Offline – Interface Dimension Change

Background: The company introduced offline store sales, requiring SKU‑specific configuration per store (price, promotion, inventory, coupons) while keeping common attributes (title, main image, specs) consistent.

Pain Points: Traditional architecture would need massive changes to interfaces, storage, and logic.

Solution: Use DDD to split data and structure; add a store dimension only in store‑related domains, leaving common domains unchanged.

General domains remain unchanged regardless of scenario.

Advantages of Domain Model and Polymorphic Handling

DDD allows adding offline sales logic without affecting existing online sales, using scenario‑based routing (similar to strategy pattern) to keep code modular and extensible.

Open/Closed principle – existing logic stays untouched while new scenarios are added.

Atomic business capabilities – offline sales are added as a separate module, easy to remove or modify.

Horizontal extensibility – the core product model can evolve into a product‑plus‑store model with minimal impact.

2. Single‑Product Page to Multi‑Product Display – Batch Interface Refactor

Background: The detail page needs to show multiple related products and handle the same product sold in different stores, requiring different logic per type.

Challenges: The page only has one primary skuId; batch processing would break domain independence if each domain stored redundant skuIds.

Solution: Mark product type in the base domain and route logic based on type; for the same product across stores, keep a single processing instance while allowing redundancy where necessary.

Example request contains skuId 555 and 888; 888 is sold in two stores, 555 in store and online. The promotion domain processes as shown:

Non‑store‑related full product domain processing:

Each domain handles its own scenarios independently, enabling vertical and horizontal extension without heavy impact on the core model.

Summary

DDD combined with polymorphic logic routing yields a stable, modular backend architecture that supports diverse business scenarios (online only, store only, or both) while preserving domain independence, adhering to the Open/Closed principle, and facilitating easy extension.

The article reflects the author’s personal experience; any errors are welcome for correction.