Designing a Marketing Reverse Domain for Refunds with DDD

Business Scenario and Trigger Conditions

A merchant runs a promotion "spend 10 CNY to receive a coupon". When a consumer places a 20 CNY order, a coupon is issued. If the consumer requests a full refund, the coupon must be reclaimed. If the consumer requests a partial refund (e.g., 5 CNY) and the order still meets the promotion threshold, the coupon is retained. The reverse domain handles these reverse operations based on defined trigger conditions:

When a refund is applied, associated marketing assets are frozen.

If the refund is cancelled or the order is closed, assets are unfrozen.

When the merchant approves the refund, assets are reclaimed after the refund completes.

If the refund amount changes, the system decides whether to freeze or unfreeze assets according to the new amount.

The threshold for reverse actions must match the forward issuance threshold; assets must be processed even when the order does not meet the issuance threshold.

Marketing Asset Types

Marketing assets are virtual rights granted when an order satisfies promotional thresholds. Common assets include coupons, discount codes, points, stored value, and virtual rights such as bargaining, assistance, or lottery participation.

Assets are classified by value attribute:

Gold‑backed assets : store value, cash red packets, JD beans, etc. They are directly tied to money and can be used without conditions.

Ordinary assets : coupons, points, etc. Their marketing value exceeds their monetary value. Reverse operations on gold‑backed assets are stricter, while ordinary assets rely more on merchant‑level risk control.

Domain Model Construction (DDD‑style)

The domain layer depends only on internal common packages. Dependency and infrastructure layers invert dependencies onto the domain layer, shielding external implementations. The application layer connects to the transaction system via extension points to handle requests and external queries.

Entities

Goods : Represents products in the order, participating products, and refund products. Provides calculations such as remaining amount and logical relationships between goods.

Equity : Unified abstraction of various virtual assets, typically derived from forward snapshots. Supplies behavior for asset operations and statistical views.

ConditionTable : Abstract representation of issuance rule conditions parsed from forward snapshots. Offers generic parameter conversion behavior.

Value Objects

Order : Order information from the upstream transaction system, including items and amounts.

RefundOrder : Refund request details, including refunded items, refund amount, quantity, and refundable amount.

Aggregate Root

RefundActivity aggregates the condition, goods, and equity entities into a single refund activity, exposing a unified operation interface.

Service

Calculate deductible amount.

Perform reverse operations on assets.

Query order‑asset information.

Context

RefundContext holds contextual information for the reverse domain (order, refund details) and supplies it to the custom rule engine.

Forward‑Reverse Domain Mapping

Different domains do not share underlying data, making it difficult for the reverse domain to interpret forward model snapshots. A model relationship mapping is introduced to translate models and parameters across domains.

Example: a "full‑X" condition model in the forward domain contains two parameters ( amountAt for the full‑X amount and amount for the actual X amount) and two option bindings ( amountPrice for full‑X amount, amountNum for full‑X quantity). The mapping configuration is expressed in an XML‑like syntax:

<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>

Key tags: identification: defines the receiving model. params: lists parameters under the model. param (key attribute): names a parameter. mapping: specifies the source domain, source model (meta_id), and the bound value (bind) for the parameter.

Defining such mappings enables direct conversion from the forward (A) domain model to the reverse (B) domain model, eliminating manual parsing and reconstruction.

Review and Future Work

Business requirements lead to varying reverse thresholds. For example, a coupon may be reclaimed only on a full refund, making the reverse threshold stricter than the forward one. Future work includes providing generic refund templates configurable with simple conditions such as "AtOnce" or "All".

The reverse domain can be extended to any scenario involving virtual‑asset refunds, e.g., stored‑value card promotions or refunds of stored‑value accounts.

Conclusion

The marketing reverse domain isolates refund logic from specific business code, abstracts rules, and supports configuration‑driven reverse processes across multiple refund scenarios. Its design yields a stable, encapsulated, and reusable capability that can be further abstracted and integrated with other middle‑office systems.