How AI Transformed a Taobao Service‑Package System with Domain‑Driven Design

Background

The Taobao flash‑sale service‑package system grew rapidly, but adding a new service‑package type required 5‑8 person‑days and involved modifying dozens of files. The monolithic code (~3,800 lines) mixed multiple business domains, duplicated product‑type checks, and suffered from high coupling and low extensibility.

Refactor Goals

Reduce development effort for new service‑package types.

Eliminate duplicated code and tightly coupled logic.

Separate responsibilities by domain context (product, price, contract, activity, etc.).

Improve testability and extensibility.

AI‑Assisted Architecture Design

An AI model analyzed the existing codebase, automatically identified domain boundaries and bounded contexts, and suggested a Domain‑Driven Design (DDD) architecture. The AI then generated skeleton domain models, service interfaces, and repository interfaces (named with Domain, DomainService, DomainRepo suffixes) and set up continuous code‑quality monitoring.

Implementation Steps

AI‑assisted domain identification : The AI parsed the package structure and produced initial context diagrams.

Human refinement : Domain experts corrected the AI’s boundaries where business semantics were missing.

Code generation : Using the refined model, AI generated domain classes (e.g., ProductDomain, PriceDomain), service interfaces, and repository interfaces.

Integration : The generated code replaced the monolithic method queryConfirmableProgramList with a step‑by‑step pipeline delegating to each domain service.

Key Code Snippets

Before refactor (core method)

@Override
public SingleResponse<ConfirmableServiceProgramDTO> queryConfirmableProgramList(ConfirmableProgramQuery query) {
    // step.1 Validate parameters and fetch shop info
    if (query == null || query.getShopId() == null) {
        return SingleResponse.buildFailure("Parameters cannot be null");
    }
    ShopInfoDTO shopInfo = shopQueryAbility.queryShopInfo(query.getShopId());
    if (shopInfo == null) {
        return SingleResponse.buildFailure("Shop does not exist");
    }
    // step.2 Get contract list (contract context)
    List<ShopContractDomain> contracts = shopContractDomainService.getShopConfirmableContractList(shopInfo);
    // step.3 Product validation (product context)
    contracts = goodsDomainService.filterAvailableContracts(contracts, shopInfo);
    // step.4 Price calculation (price context)
    contracts = priceDomainService.enrichContractPrice(contracts);
    // step.5 Activity matching (activity context)
    contracts = activityDomainService.applyActivityDiscount(contracts, shopInfo);
    // step.6 Build DTO
    ConfirmableServiceProgramDTO result = buildConfirmableServiceProgramDTO(contracts);
    return SingleResponse.of(result);
}

After refactor (pipeline)

@Override
public SingleResponse<ConfirmableServiceProgramDTO> queryConfirmableProgramList(ConfirmableProgramQuery query) {
    // step.1 Get shop domain
    ShopDomain shopDomain = shopDomainService.getShop(query.getShopId());
    // step.2 Get confirmable contracts (contract domain)
    List<ShopContractDomain> contracts = shopContractDomainService.getShopConfirmableContractList(shopDomain);
    // step.3 Filter contracts by product rules (product domain)
    contracts = goodsDomainService.filterAvailableContracts(contracts, shopDomain);
    // step.4 Enrich contracts with price information (price domain)
    contracts = priceDomainService.enrichContractPrice(contracts);
    // step.5 Apply activity discounts (activity domain)
    contracts = activityDomainService.applyActivityDiscount(contracts, shopDomain);
    // step.6 Convert to DTO
    ConfirmableServiceProgramDTO result = buildConfirmableServiceProgramDTO(contracts);
    return SingleResponse.of(result);
}

Refactor Effects

Core logic size reduced from ~1,500 lines to ~720 lines.

Development effort for a new service‑package type dropped from 5‑8 person‑days to a configuration‑only change.

Duplicate product‑type checks eliminated (100% removal).

Responsibility clearly separated per domain, improving testability and supporting the open‑closed principle.

Comparison Before and After

Before refactor, adding a new product required changes in multiple core methods ( queryConfirmableProgramList, queryConfirmableCombineProgramList, signProgram) across 8 files and 15‑20 methods. After refactor, the change is confined to a single domain service and a small configuration entry, reducing the number of modified files and lines of code dramatically.

Key Takeaways

AI can quickly surface repeated patterns and suggest domain boundaries.

Human expertise is still essential for semantic validation.

Combining modular DDD design with AI‑generated code yields substantial efficiency gains, lower risk, and easier maintenance.