ポイント

設計のポイント

付与率の計算

顧客ランク (ロイヤルティ)

還元率アップキャンペーン

期間限定

店舗限定

ポイント付与のタイミング

即時

後日

キャンセル可能なアクションを伴うポイント付与は、キャンセルできなくなるタイミングまで実際の付与を遅らせる。

ただし、付与予定としてユーザに見せるケースがある。

ユーザがキャンセルした場合は、付与予定を取り消す。

有効期限

固定(dポイント型)

使うたびに延びる(ヨドバシ型)

期間限定ポイント

キャンペーンとして有効期限の短いポイントを対象ユーザに一斉に付与する。

↑の有効期限が使うたびに延びるタイプでも、期間限定ポイントは固定の有効期限を持つ。

参考資料

モデリング

考慮点

ポイントを付与した、利用した、失効した、の事実は失われてはならない

ポイントの残高はあらゆるところで表示されがち。

ポイントの残高以上にポイントが利用できないよう制限する。

付与予定や失効予定のポイントを一覧表示することがある

論理設計

上記、設計のポイントにより、細かなバリエーションは発生するが、事実が失われないように記録しつつ、参照のたびに大量の算出ロジックを走らせないためには、次のようなモデルが基本形になるかと思われる。

残高は取引、仕訳から求められるが、参照頻度が高いので導出項目として物理的に持っておいた方が良い。

ポイントを貯めておく場所を「ウォレット」として定義し、ここに残高を持たせる。

会計モデルの取引、仕訳は基本的に全ての(ポイント含む)金銭的なやり取りが記録される。

現在有効なポイントを容易に求められるように、ポイント付与時に「部分利用可能な有効期限つき金券」が発行されたメタファを使い、これを金券モデルとして「獲得ポイント」「ポイント消込」としてエンティティを作る。

https://gyazo.com/dc37760767bdbff4b4e7826d4c87a89b

table:取引

ID 取引日時

1 2023/1/1

2 2023/1/9

table:仕訳

ID 取引ID 科目 金額

1 1 売掛金 -1000

2 1 売上高 900

3 1 ポイント付与 100

4 2 ポイント利用 -50

5 2 売上高 50

table:獲得ポイント

獲得仕訳ID ウォレットID 有効期限

3 1 2023/3/31

table:ポイント消込

獲得仕訳ID 消込仕訳ID

3 4

物理設計のために考慮すること

データ量が多い場合、パーティショニングを考える

会計モデルのテーブル群は、過去分を参照する機会はほとんどないと考えられるので、取引日時に応じたレンジパーティションすると良い。ついでに過去分をまとめてパージできるようになる。(といっても最低10年は保管の必要がある)

金券モデルのテーブル群は、ウォレットを跨いだSQLは発行しないはずなので、ウォレットIDをキーにハッシュパーティションにすると、分散アクセス効率が高くなる。