Designing a Marketing Reverse Domain for Refund Asset Management

Introduction

Merchants often encounter problems when refunds affect marketing assets: coupons may not be reclaimed, the refund process lacks visibility of asset status, and malicious actors may try to exploit promotional benefits. A Marketing Reverse Domain was created to handle reverse operations on marketing assets, providing capabilities to freeze, unfreeze, and reclaim assets.

Business Scenario

Consider a promotion that grants a coupon for every purchase over ¥10. A customer places a ¥20 order and receives a coupon. If the customer requests a full refund, the merchant wants the coupon reclaimed. If the same customer requests a partial ¥5 refund, the order still meets the threshold, so the coupon remains valid. The reverse domain evaluates the refund request, the original issuance threshold, and the asset type to decide whether to freeze, unfreeze, or reclaim the asset.

Marketing Asset Types

Marketing assets are virtual benefits issued when an order satisfies a promotional rule. Typical assets include:

Coupons and discount codes

Points

Stored value (e.g., cash red packets, store credit)

Virtual rights such as bargaining, assistance, or lottery participation

Assets are classified by value attribute:

Gold‑standard assets : Directly tied to monetary value (e.g., stored value, cash red packets).

Ordinary assets : Marketing value exceeds monetary value (e.g., coupons, points).

Trigger Conditions

During a refund request the system follows a state‑machine:

Freeze assets when a refund is initiated.

Unfreeze assets if the refund is cancelled or the order is closed.

Reclaim assets when the merchant approves the refund and the refund is completed.

The decision to freeze or unfreeze also depends on whether the refund amount changes. The reverse‑action threshold must match the original issuance threshold; otherwise the asset is processed according to the configured rule.

System Positioning

The reverse domain resides downstream of the transaction chain in the middle‑platform layer. It is invoked only after an order is placed and a refund occurs. Although request volume is low, the domain requires high computational accuracy.

Model Construction

The implementation follows Domain‑Driven Design (DDD). The domain layer depends only on internal common packages; the dependency and infrastructure layers invert dependencies to keep external implementations out of the domain. The application layer connects to the transaction system via extension points to handle requests and queries.

Domain Design

Entities

Goods : Represents items in the order, participation in promotions, and refunded goods. Provides calculations such as remaining amount and logical relationships between goods.

Equity : Unified abstraction for all virtual assets, derived from forward‑snapshot data. Offers asset‑operation methods and statistical views.

ConditionTable : Encapsulates promotional rule conditions parsed from forward snapshots and supplies generic parameter‑conversion behavior.

Value Objects

Order : Information supplied by the upstream transaction system, including order items and total amount.

RefundOrder : Details of a refund request generated by the transaction system, containing refunded items, requested amount, quantity, and refundable amount.

Aggregate Root

RefundActivity : Aggregates ConditionTable, Goods, and Equity into a single refund activity. Exposes unified operations with clear boundaries.

Service

RefundService : Provides three core capabilities—calculating deductible amounts, performing reverse asset operations, and querying order‑asset information.

Context

RefundContext : Holds contextual data for the reverse domain, such as order and refund details, supplied by the rule engine.

Forward‑Reverse Domain Mapping

During development a mismatch between forward‑domain snapshots and reverse‑domain models prevented direct reuse of snapshot data. The solution is an explicit model‑mapping configuration that translates parameters from the forward domain to the reverse domain.

<identification name="ump.refund.setting.amount.num.resource">
    <params>
        <param key="amountNum">
            <mapping domain="UMP" meta_id="ump.pbb.condition.amountOver" bind="amountNum"/>
        </param>
    </params>
</identification>

The identification element defines the target model, params lists the parameters, key names each parameter, and mapping specifies the source domain, source model ( meta_id), and the bound value ( bind) to import.

Reflection

Business requirements may demand reverse thresholds that differ from forward thresholds—for example, reclaiming coupons only on a full refund. Future work includes providing generic refund templates (e.g., "AtOnce" or "All") to simplify configuration, extending the reverse domain to cover other virtual‑asset refund scenarios such as stored‑value card refunds, and handling gold‑standard asset reversals.

Prior to the reverse domain, marketing activities listened to refund messages and scattered logic across components, making maintenance difficult. The new domain abstracts rules, decouples refund logic from specific business code, and centralizes configuration.

Conclusion

The Marketing Reverse Domain addresses asset reclamation during refunds, supports multiple refund scenarios, and enables configurable reverse processes. Compared with the order domain, the reverse domain is relatively stable, encapsulated, and reusable. Further abstraction and integration with other middle‑platform systems are planned.