How DDD Transformed Our E‑Commerce Discount Center: A Practical Refactor

Preface

As Eric Evans described in his book, Domain‑Driven Design (DDD) is a way to tackle core software complexity.

When solving real business problems we encounter intricate logic; the same concept, such as “product”, can mean different things in product detail, order, or logistics contexts.

DDD’s core idea is to let the correct domain model work. It encourages dividing sub‑business units into sub‑domains and modeling each separately.

Part 1 – Background of Refactoring the Discount Center

Initially, to speed up development and reduce risk, a single large model was shared across modules. As business grew, the model became a maintenance nightmare: changes for sub‑domain A unintentionally affected B or C.

The discount center manages promotional activities and calculates discounts for users. Product Management and Discount Management were initially sharing one product model.

Problems Identified

Inflexible functionality : Discounts were configured as product attributes, requiring manual updates for time‑sensitive promotions and repetitive configuration for global discounts.

Difficult to extend : Adding a new discount type meant expanding product tables, bloating the schema and risking impact on product management.

Hindering iteration : Without a dedicated lifecycle, it is hard to measure ROI of a discount and guide future optimizations.

Refactor Expectations

System level : Isolate discount‑related logic into its own bounded context.

Application level : Provide an independent admin for managing discounts and a separate calculation service for C‑end users.

Part 2 – Why Choose DDD

Avoiding Anemic Models

Traditional MVC often leaves the Model as a pure data object while business logic lives in Services, creating “anemic” models that lose behavior and become hard to maintain.

DDD promotes modeling based on behavior, keeping logic within domain objects and reducing loss of business intent during iteration.

Part 3 – Implementation Process

Key: Abstract Business Logic

Domain experts and developers must collaborate to extract core business rules, e.g., distinguishing product types and discount applicability.

Step 1 – Unified Language

Define key terms such as Discount Type, Discount Activity, Discount Discovery, Discount Calculation, Discount Sorting, and Discount Conflict.

Step 2 – Abstract Domain Model

Distinguish Entities (stateful, identifiable) from Value Objects (stateless, immutable). For example, a Discount Activity is an entity, while a Discount Type is a value object.

Step 3 – Define Aggregates

Group related domain objects under aggregates, e.g., Discount Activity aggregates Discount Types, Discount Ranges, etc.

Step 4 – Iterate Model with Scenarios

Adjust the model as business evolves, such as adding new discount types that require changes to the aggregate.

Step 5 – Simplify Design

Remove unnecessary abstractions, e.g., generating discount types automatically proved unused and was eliminated.

Strategic Design

Strategic design handles bounded‑context separation and integration. The discount center operates as a sub‑domain within a larger e‑commerce system, requiring context mapping for upstream services.

Integration Patterns

Client‑Supplier : Tight collaboration with automated tests.

Conformist : Upstream ignores downstream contracts.

Anti‑Corruption Layer : Translate upstream data to protect the domain.

Open Host Service : Suitable for platform services.

Given the team structure, an Anti‑Corruption Layer was chosen.

Architecture Implementation

The discount center uses a classic layered architecture: UI layer, Application Service layer, Domain layer, and Repository layer.

User Interface Layer : Handles interaction with end users.

Application Service Layer : Wraps and converts domain data for the UI.

Domain Layer : Core business logic, domain objects, and services.

Repository Layer : Persists domain objects and abstracts storage details.

Part 4 – Issues and Near‑Term Plans

1. Price‑Level Discounts

Without a unified product center, different lines define products differently, making a generic discount model risky. The solution may involve establishing a unified product center.

2. Performance

DDD increases class count; PHP’s interpreted nature adds overhead. Future work plans to rewrite the discount center in Java for better performance.

Part 5 – Summary

This article shares practical experience refactoring the discount center at a large e‑commerce platform using DDD, which helped create a more rational architecture during rapid business growth. Whether to adopt DDD depends on specific business and team contexts, and further exploration will continue.