Why Embedding Marketing Logic in the Order API Was a Mistake (And How to Fix It)

Initial Approach

The order‑generation service contained a single class of more than 1,600 lines and injected over twenty dependencies, many of which were marketing‑related services such as full‑off, seckill, cut‑price, special‑price, and coupon services. These services lived inside the order codebase and were deployed together with the order service.

@Autowired private FullOffOrderService fullOffOrderService;
@Autowired private SeckillOrderService seckillOrderService;
@Autowired private CutpriceOrderService cutpriceOrderService;
@Autowired private TejiaService tejiaService;
@Autowired private CouponV3Service couponV3Service;

Method Bloat

The core order‑creation method, responsible for building the main order, sub‑orders per supplier, and SKU‑level orders, grew to more than 700 lines. For each SKU it first determined which marketing activity applied, using eight boolean flags:

boolean isSeckillOrder = seckillOrderService.isSeckillOrder(reqSku);
boolean isCutpriceOrder = cutpriceOrderService.isCutpriceOrder(reqSku);
boolean isTejiaOrder = tejiaService.isTejiaOrder(reqSku);
boolean isFullOffOrder = fullOffOrderService.isFullOffLittleOrder(reqSku);
boolean isJobCenterOrder = jobCenterOrderService.isJobCenterOrder(reqSku);

These flags fed a massive if‑else chain that executed distinct price‑calculation logic for each activity. The full‑off calculation alone occupied nearly 100 lines to handle capped and uncapped discount rules and multiple thresholds, even though it had no relevance to order creation.

Consequences

Release cadence hijacked : Marketing introduced new activities weekly, forcing the order team to modify, test, and release the order service for every change.

Testing scope expanded : A tiny change to a full‑off rule required regression testing of the entire order flow, including seckill, cut‑price, and coupon logic.

Fault domain enlarged : Misconfigured marketing activity times caused the order service to throw exceptions, leading to large‑scale order‑API failures.

Collaboration overhead : Order and marketing teams had to constantly align interfaces, making each other's release schedules dependent.

Hard‑Coded Switch Example

switch (activityType) {
    case 0: break; // normal product
    case 1: checkSecKillSku(); break; // seckill
    case 3: checkFullOffSku(); break; // full‑off
    case 8: checkCutPriceSku(); break; // cut‑price
    case 9: checkTejiaSku(); break; // special price
}

Each new activity required adding another case, turning the switch into a maintenance nightmare.

Root Cause

The order service was responsible for marketing‑domain logic that should belong to a separate system. It should only receive the final discount amount, not compute how that amount is derived.

Correct Approach

Introduce an independent settlement (结算) service that acts as a boundary between the order system and the marketing system. The settlement service queries active marketing rules, computes applicable discounts based on the cart or order items, and returns a discount‑detail object to the order service.

Call flow after refactor:

User submits order.

Front‑end calls the settlement service to obtain discount information.

Order service receives the discount detail and creates the order without any marketing‑specific logic.

Resulting changes:

Injected dependencies in the order service dropped from >20 to a single‑digit count.

The order‑creation method shrank from >700 lines to under 200 lines, with all activity‑type checks removed.

Order‑service release frequency fell from 1–2 times per week (mostly marketing‑driven) to 1–2 times per month, driven only by core order‑business changes.

Marketing changes now affect only the settlement service, isolating faults and simplifying testing.

Outcome Metrics

Release frequency: weekly → monthly.

Method line count: 700+ → <200.

Dependency count: 20+ (majority marketing) → single‑digit (order domain only).

Impact of marketing changes: order service must change → only settlement service changes.

Fault isolation: marketing config error caused order failures → settlement service can degrade while order service remains healthy.

Key Takeaway

Embedding marketing logic directly in the order interface works when activity types are few, but each incremental addition creates hidden coupling. When two subsystems have mismatched change frequencies—stable order processing versus volatile marketing—introducing a dedicated middle layer preserves stability, reduces release overhead, and improves fault isolation.