配捐系統模型設計

本篇主要明確配捐系統的概念和具體實現，包括數據結構設計、邏輯關係分析等。

什麼是配捐？
配捐的概念誕生於1954年，由美國通用基金會創造。截止2016年，通用的總計配捐總額達到3800萬美圓。最初只是贊助員工母校的貧困學生，以後逐漸延伸到其餘公益領域，也帶動了其餘企業加入配捐大潮。

網上釋義： 本身找吧；

個人釋義： 配捐是一種公益活動，參與用戶的某種公益行爲在知足活動合約中設定的捐款條件後，會觸發活動的參與企業以用戶的名義爲項目捐款。簡單來講就是"你出力，我出錢"。

常見的配捐有如下幾種形式：

1. 分享配捐：用戶分享成功一次，公益企業捐出必定數量的$。
2. 捐款配捐：用戶捐款多少，公益企業就按必定比例捐出多少。

從業務本質上來講，配捐實際上屬於一種活動，因此在作系統設計時應看成活動來設計。

數據模型設計

一般「活動」是在後臺配置，包括：發佈、修改、下線、上線活動。那咱們先大概肯定下「活動」的相關數據結構。

配捐活動的主要結構以下：

活動類型表「activity_type」

id: {type: 'integer', primaryKey: true, autoIncrement:true} //活動類型ID
activityType: {type: 'string', required: true} //活動類型：分享配捐|捐款配捐|…
createdAt：{type: 'timestamp', required: true}

活動類型不可刪除；

活動表「activity」

id: {type: 'integer', primaryKey: true, autoIncrement:true} //活動ID
activityTypeID: {type: ‘integer', required: true} //活動類型ID：
activityName: {type: ‘integer', required: ture} //活動名稱, 如：分享配捐第一期
activityImages: {type: ‘text', required: false} //活動圖片/封面
startTime: {type: ‘timestamp', required: ture} //活動起始時間
endTime: {type: ‘timestamp', required: ture} //活動結束時間
createdAt: {type: 'timestamp', required: true} //活動建立時間
updatedAt: {type: 'timestamp', required: true} //活動修改時間
remark: {type: ‘text', required: false} //活動規則備註
state: {type: ‘integer', required: true} //活動狀態

配捐活動明細表「Activity_matching_gift」

id: {type: 'integer', primaryKey: true, autoIncrement:false} //活動ID
donationAmount: {type: 'decimal(11,2)', required: true} //配捐金額
donationProportion: {type: 'string', required: true} //配捐比例
Donors: {type: 'string', required: true} //配捐參與企業, json字符串 {「charity1」,」charity2」,」charity3」,"…"}

後臺界面上根據活動類型加載活動明細表。
活動期間和活動結束後均不得修改活動內容，若是要修改只能夠在活動以前修改。

在具體實現時咱們還須要考慮配捐與用戶、活動、分享、訂單等系統之間的邏輯關係。既然講到實現，那咱們就要明確到底要實現什麼。

先拿「分享配捐」來講吧。從產品需求中得知有如下幾點：

• 用戶登陸&分享成功後，觸發企業捐款；可是在捐款列表中顯示的是分享用戶的相關信息。因爲參與的第三方企業不能作到實時捐款，因此會在捐款列表中標記XX機構將會配捐多少。
• 一個用戶一天以內能夠分享屢次，可是企業一天只配捐一次，無論該用戶分享了多少次。

實現過程當中的問題和解決方案：

1. 捐款列表是已支付的訂單。用戶分享後要在捐款列表中馬上顯示分享用戶的信息，而用戶只是分享並無實際捐款，如何解決這個問題？
   解決方案是爲該用戶建立一個訂單金額爲0的訂單，即空訂單。
2. 第三方企業不能作到實時捐款，那麼就要求訂單和待配捐的任務必需要有一個關聯，以便系統能夠異步定時處理這些配捐任務。那麼用戶-活動-分享-訂單之間到底如何創建關係合適呢？是否能夠根據分享訂單查詢企業是否真實捐款了呢？
3. 前端捐款列表頁面如何作到對於不一樣的捐款活動展現不一樣的樣式風格呢？

其實「2」和「3」的解決方案是同一個。讓咱們進一步分析下：

• [x] 用戶-參與-活動-分享

用戶參與，參與什麼呢？參與活動，什麼活動呢？分享捐款活動，在活動中作了什麼事呢？分享！

• [x] 企業-參與-活動-捐款-訂單

企業參與，參與什麼呢？參與和用戶一樣的活動，什麼活動呢？分享捐款活動，在活動中作了什麼事呢？捐款，生成捐款訂單！

如今，咱們把用戶參與活動的事件及流程，抽象在一張「活動事件表」裏。

活動事件表「Activity_event」

id: {type: 'integer', primaryKey: true, autoIncrement:true} 
userID: {type: 'string', required: true} //用戶ID
activityID: {type: 'integer', required: true} //活動ID
activityTypeID: {type: 'integer', required: true} //活動類型ID
userEventID: {type: 'integer', required: true} //用戶事件ID，這個事件多是分享也多是別的，因活動類型而定；用戶分享ID|... 
remark: {type: 'string', required: false} //備註
createdAt：{type: 'timestamp', required: true}
state: {type: 'integer', required: true} //活動事件狀態，未完成|已完成

「活動事件表」裏即記錄了活動關係，也記錄了待處理的異步任務。

後期與配捐的企業結算也須要這張表。

活動事件訂單表「Activity_event_order」

id: {type: 'integer', primaryKey: true, autoIncrement:true} 
eventID: {type: 'integer', primaryKey: true, autoIncrement:true} //活動事件表ID
orderID: {type: 'string', required: true} // 訂單ID，若是是分享事件，那麼這裏多是用戶分享後生成的空訂單ID，也多是企業配捐的訂單ID
remark: {type: 'string', required: false} //備註，好比能夠標註訂單的性質，share|matchingGift
createdAt：{type: 'timestamp', required: true}

爲何須要「活動事件訂單表」呢？由於不一樣類型活動的事件，或同一種事件，今天多是對訂單有影響，明天多是對積分有影響。因此必須把具體被影響的對象抽象出來。

「活動事件訂單表」表示這個「事件」是對訂單有影響，記錄的是事件和訂單的關係。

若是一個分享訂單對應有兩個企業配捐，那麼這個表一個產生3條記錄。一個用戶分享的空訂單ID，兩個企業捐款的訂單ID，三個都對應同一個事件ID。

最後 「訂單表」 關聯 「活動事件訂單表」 和 「活動事件表」 就能夠解決上面 「2」和「3」 的問題。 這樣設計的優勢就是從數據結構層作到系統解耦，既不須要修改訂單表、分享表和活動表又能夠靈活擴展。