大廠的營銷逆向域 DDD 實踐

0 商家的痛點

訂單退款後優惠券沒被回收、退款過程中商家對營銷資產沒有直觀感知、黑產黨嘗試薅商家資產羊毛等，給商家造成不好體驗。爲此構建營銷逆向域，如資產凍結、解凍、回收等能力。

1 業務形態

商家設置一種滿 10 元送優惠券的活動，而後消費者下筆 20 元訂單得到一張優惠券，然後申請訂單全額退款，商家希望能回收優惠券。

而另一位消費也花 20 元，只申請 5 元部分退款，商家表示訂單達到門檻，不打算回收券。這是最基礎的一個業務場景，營銷逆向域就是處理該券的逆向操作，技術則關心觸發逆向的條件和對應的營銷資產種類。

1.1 營銷資產種類

營銷資產，指訂單滿足某些營銷活動的門檻後由營銷系統發放給消費者的虛擬資產或權益。常見有優惠券、優惠碼、積分、儲值金等；虛擬權益有砍價，助力，抽獎等（消費者在消費後可以獲得一定的資格參與其他互動類的活動），營銷資產利於促進消費者回購，幫商家穩定客源。

按虛擬資產的價值屬性區分：

• 金本位資產

  店鋪儲值、現金紅包、京豆等，這類資產的特點是與資金直接掛鉤，均可直接用來無門檻消費

• 普通資產

  優惠券、積分等，本身不與資金直接相關，營銷價值大於資產價值。對金本位資產的逆向操作更嚴肅，普通資產的風險控制更多由商家操作

1.2 按資產價值分類

1.2 觸發條件

• 買家申請退款時，需凍結營銷資產

• 買家撤銷退款或各種關單場景，需解凍資產

• 商家同意退款，退款完成需要回收資產

• 買家修改退款單時需要看申請金額的變化，來決定凍結還是解凍資產

門檻需要與正向發放的門檻需要保持一致，即不足發放門檻時，需要處理資產。關於凍結解凍回收狀態機如下圖所示：

img

在整個交易鏈路，營銷逆向系統在中臺的位置處於逆向鏈路下游，在用戶下單行爲完成後且發生退款才涉及，流量不高但計算精準性高要求，中臺位置：

由產品配置活動的逆向規則，實際退款按配置規執行。下單鏈路會提供活動的快照信息如優惠門檻、發放資產等。營銷逆向域依賴規則引擎，負責底層組件調用，最終通過發放中心異步操作資產，一次退款的主要業務流程如下：

2 模型構建

爲保持領域層（domain）整潔，只依賴內部 common 包，依賴層（dependency）和基礎設施層（infrastructure）通過依賴倒置方式依賴領域層，屏蔽外圍的接口實現。上游應用層（application）以拓展點接入交易系統，處理請求和外部查詢。參考 DDD 得到包結構：

2.1 領域設計

領域模型需要保證高內聚低耦合，有對應的行爲支撐模型的屬性：

①  實體（Entity）

• 商品（goods）：訂單中的商品、活動參與商品和退款商品，具有商品各種計算能力，如判斷商品的剩餘金額，商品之間各種邏輯關係等

• 資產（equity）：各類虛擬資產的統一抽象，一般來自正向的快照信息，提供資產操作的行爲和各種統計視圖

• 門檻（conditionTable）：抽象活動的發放規則條件，由正向的 snapshot 解析而來。提供通用化的參數轉化行爲

② 值對象（ValueObject）

• 訂單（order）：上游交易告知的訂單信息，包括訂單商品，金額等信息

• 退款單（refundOrder）：同樣由交易產生，包括了申請退款的商品，申請的退款金額，件數以及可退金額等信息

③ 聚合根（Aggregate）

活動聚合（refundActivity）：對門檻、商品和資產實體做一個整體的聚合，抽象成一個退款活動，對外統一操作。

④ 服務（Service）

在領取層統一提供 refundService 服務，提供能力：

• 計算抵扣金額

• 資產逆向操作

• 訂單資產信息查詢

⑤ 上下文（Context）

RefundContext：逆向域的上下文信息，包括訂單退款單等，在定製規則引擎中提供上下文服務。

2.2 正逆向領域映射

開發難題

因爲不同領域之間底層數據不互通，使得逆向域解析正向模型時變得十分困難，導致正向域產生的優惠快照（snapshot）在逆向域無法被識別。

對此，採用模型關係映射，解決不同領域間模型和參數的轉化問題。以滿 X 條件模型爲例，正向模型有：

• 兩個參數：

• amountAt 滿 X 元（件）

• amount 實際 X 元（件）

• 兩個 optionBind 綁定條件：

• amountPrice 滿 X 元

• amountNum 滿 X 件

高度抽象靈活的模型，不同參數綁定表示不同業務含義，但也帶來問題，如：

• 滿 X 元、滿 X 件的業務校驗邏輯不同，在流程中除了要關心模型本身是啥，更要關心模型綁定的參數，破壞內聚原則

• 用戶僅退款場景，沒有件數信息，存在特殊邏輯

所以逆向域構建過程中，採用含義清晰的積木。實際映射配置：

<identification >
    <params>
        <param key="amountNum">
            <mapping domain="UMP" meta_id="ump.pbb.condition.amountOver" bind="amountNum"/>
        </param>
    </params>
</identification>

• identification標籤定義受體模型

• params定義模型下的參數列表

• key定義模型下的參數名

• mapping定義參數值的來源，從哪個領域（ domain）的哪個模型（ meta_id）中取哪個綁定（ bind）或者參數 ( value)

定義模型映射關係，即可直接將 A 領域的模型轉換成 B 領域的模型（包含參數），省去業務自己去解析積木，轉換參數，再構建的過程。

3 覆盤

存在正逆向的門檻條件不同業務需求，如雖下單滿足指定金額送優惠券，但只要發生退款即回收券，此時逆向的門檻條件高於正向，又或者訂單金額全退纔回收優惠券等，未來逆向域考慮提供通用的退款模板，只需配置 “AtOnce” 或“All”這樣的普通條件即可實現條件判斷。

逆向域作用範圍可再拓展，涉及退款退虛擬資產的業務都可接入，如充值儲值卡送優惠券，用戶退儲值賬戶，也可接入營銷逆向域。

逆向域誕生前，營銷活動通過監聽退款消息來做邏輯，雜糅在系統各組件。新系統打散活動的概念，抽象出各種規則，使退款不再依賴於具體業務，而依賴於各種配置規則。

4 總結

本文解析營銷逆向域的業務形態及逆向域的領域實踐，解決資產的逆向回收，支持多種退款場景，支持不同業務規則，實現逆向流程配置化。

相比下單域，逆向較穩定，易收攏業務、方便制定規則、能力可複用。但在領域設計上還可繼續抽象與中臺其他系統聯動。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/TYm7EcZGikIg-zuahmIKNQ