How DDD Handles Four E‑Commerce Payment Changes Step‑by‑Step

Many projects break when requirements change—adding a discount feature forces a rewrite of the payment module, and introducing VIP members triggers widespread if‑else modifications. The root cause is often a flawed design approach rather than poor code quality.

Step 1: From Requirement to Domain Model

The first DDD activity is modeling. For an e‑commerce payment system, the requirements mention order , user , and product . These three entities are extracted and their relationships clarified: an order belongs to one user, a user can have multiple addresses, an order contains multiple line items, and each line item references a product. After defining the operations—place order, pay, view status—a domain‑model diagram is produced. This diagram becomes a “map” for the code: an Order Service handles order‑related logic, a User Service handles user‑related logic, and each service has a single responsibility.

Step 2: Using the “Two Questions” to Decide Splitting

When a discount feature arrives—covering time‑limited, quantity‑limited, and category‑specific discounts—the instinct is to add nested if‑else statements inside the payment method. DDD advises pausing and asking two questions: “When the payment changes, does the discount have to change?” and “When the discount changes, does the payment have to change?” If both answers are “no”, the concerns have different reasons for change and should be separated. This follows the Single Responsibility Principle: code that changes for different reasons must be isolated.

Consequently, the discount logic is extracted into its own interface, with separate implementations for each discount type. Future changes to a specific discount affect only its class, leaving the payment code untouched.

Step 3: Continuous Model Evolution Driven by New Requirements

When VIP members are introduced, the payment flow must also expand. The same “two‑question” analysis is applied. VIP membership concerns (discounts, benefits, privileges) are independent of user registration, so they are split into separate services. Payment methods are also split: the Order Service now depends on a generic "PaymentMethod" interface rather than directly invoking Alipay or WeChat Pay. An Adapter pattern is introduced for each concrete payment provider.

With this design, a change in the Alipay API only impacts the Alipay adapter; a change in WeChat Pay only impacts its adapter. Adding a new payment channel merely requires a new adapter implementation, dramatically shrinking the change scope and lowering maintenance cost.

DDD Change‑Management Template

The overall process can be summarized as:

Receive requirement → Build domain model

Ask the two questions → Determine responsibility boundaries

Split when needed → Let the model guide code

When change arrives, return to the model

The core message: do not rush to code; first clarify the business world. The domain model serves as a “battle map” that tells you exactly where to modify and where not to when requirements evolve.

Design Evolves with Business

Many developers think design is a one‑time activity—draw an architecture diagram and follow it. DDD asserts that design grows together with the business. When requirements stay stable, the design remains stable; when requirements shift, the model is updated first, then the code follows. This dynamic approach is the true power of DDD.