How to Build an Event-Driven Strategy Center for Full-Chain Marketing

Project Background

Full‑chain marketing is a decentralized operation that issues fine‑grained marketing rights to users by building a strategy‑center system. User behavior records are used to match product preferences, and after satisfying strategy rules, the C‑side triggers the issuance and expression of rights.

Architecture Design

Current marketing applications use the TMF framework, where the middle platform provides standard nodes and the marketing business layer composes them. Each node offers extension points, allowing different marketing tools to implement various play‑styles.

The marketing calculation flow is relatively fixed; business iteration usually extends nodes in the current flow, and TMF’s extension points use the Strategy pattern (e.g., a copy‑building node returns different copy based on the marketing tool type).

However, full‑chain marketing targets the play‑layer, so each iteration may have a non‑fixed business process, varying user‑behavior requirements and downstream dependencies. Different play‑templates trigger different process nodes, improving extensibility.

Full‑chain marketing has two links: data preparation and rights issuance. Data preparation occurs after user‑behavior rule validation via an MQ message; rights issuance is triggered by the strategy center when a user accesses a resource.

Each user action is treated as an event (synchronous or asynchronous). Events drive the orchestration of business nodes, which can be configured via a configuration center or hard‑coded in Java, resulting in an event‑driven process orchestration system.

System Architecture

The strategy center identifies different events through channel codes, which trigger distinct orchestration flows. Its codebase is divided into four layers:

Access layer: behavior validation, rule aggregation, and MQ notification to the strategy center; synchronous notifications from upstream.

Service layer: channel‑specific event handling, delegating to the domain layer for strategy execution.

Domain layer: contains multiple sub‑domains that can be independently composed; exposes strategy capabilities externally.

Infrastructure layer: external and storage dependencies.

Process Design

The overall code flow of the strategy center includes two main event types:

Behavior event: after a user satisfies a behavior rule, an MQ message carries a ruleKey as channelCode. The strategy center queries the activity, builds a strategy instance, prepares data (e.g., product info, algorithm recall, discount handling), and stores the instance data in Redis.

Resource‑position event: when a user clicks a resource, the API receives a channelCode, performs the same activity lookup and instance building, reads preparation data from Redis, and starts rights issuance.

Design notes:

Strategy instance logic is fixed; each play‑style corresponds to a strategy template that assembles a chain of processors. Adding a new play only requires a new template, preserving other plays.

Distributed locks ensure a single strategy instance is processed by only one thread at a time, preventing data overwrite when concurrent events occur.

Locks are applied only when necessary, configurable via parameters or template settings.

Model Design

The domain model aggregates around TacticsInstanceContext, with TacticsActivity as the aggregate root. Each instance contains the activity, execution parameters (buyer ID, channel, lock flag, etc.), and results. One activity maps to one user‑specific instance.

To extend capabilities, the context can hold a map of extra fields or implement extension interfaces. The project adopts interface‑based extension, following a Strategy + Factory pattern, allowing different templates (e.g., version 3.0) to construct appropriate contexts.

Strategy Templates

Each play corresponds to a strategy template; currently versions 2.0 and 3.0 exist. A template factory retrieves the configuration, and getProcessorChain() provides the core orchestration capability based on the channelCode.

public List<String> getProcessorChain(String channelCode) {
    List<String> processorChain = Lists.newArrayList();
    if ("channelCodeA".equals(channelCode)) {
        processorChain.add(QueryacticsProcessor.PROCESSOR_NAME);
        processorChain.add(HandleItemPromotionTacticsProcessor.PROCESSOR_NAME);
        processorChain.add(EventTacticsProcessor.PROCESSOR_NAME);
    } else if ("channelCodeB".equals(channelCode)) {
        processorChain.add(CheckEventTacticsProcessor.PROCESSOR_NAME);
        processorChain.add(RuleCheckTacticsProcessor.PROCESSOR_NAME);
        processorChain.add(QueryAssetTacticsProcessor.PROCESSOR_NAME);
        processorChain.add(SendBenefitTacticsProcessor.PROCESSOR_NAME);
        processorChain.add(BuildResultTacticsProcessor.PROCESSOR_NAME);
    }
    return processorChain;
}

The processor interface is defined as:

public interface TacticsProcessor {
    /** Node name */
    String getProcessorName();
    /** Strategy instance validation */
    boolean validate(TacticsInstanceContext instanceContext);
    /** Execution logic */
    void process(TacticsInstanceContext instanceContext);
}

Idempotency Design

The business loop issues rights only when the user has no usable asset (unclaimed, expired, or redeemed). The rights system guarantees that an idempotent ID triggers a single resource deduction and asset write, with automatic retry or rollback on failure. The strategy center enforces uniqueness of the idempotent ID and skips issuance when a usable asset already exists.

Ensure idempotent ID uniqueness and re‑entrancy.

If a usable asset exists, return it directly without issuing new rights.

Project Summary

This article presented the technical solution selection and practical implementation of the AE strategy center. From an initial flat logic design to an event‑driven orchestration system, the architecture was optimized for extensibility; future business iterations only need new strategy templates and nodes, adhering to the open‑closed principle.