主要テーブルは2つ
- ポイント
- 冪等性を確保する
- 状態管理テーブル
- 会社保有のチケット
- チケットの失効の仕様策定
- 契約テーブル
- 実装計画
- 第一phase
- 定期購読契約テーブルとバッチ状態管理テーブルを作成
- 過去のデータで不整合が生じるため削除orデータ変更
- 第二phase
- Railsアプリケーション側開発
- バッチを実装（Lambda、EventBridgeのクラウドネイティブなバッチ）
- 第三phase
- チケット失効仕様のためチケットテーブルを追加設計
- チケット失効バッチを実装
- 制約
- 定期購読停止申請は契約更新月の前月末までにしないと次回更新時になる
- 参考にしたのはNintendo Switchオンライン契約の定期購読の仕組み（ちょっと違うけど、人と会話する時に参考になりやすい）
- https://support.nintendo.com/jp/nso/automatic-purchase-extension/index.html
- チケット効力失効が新たに追加
- 定期購読停止とはまた違い、チケット自体の効力である
- Amazonポイントとかわかりやすい
- 定期購読契約テーブル
- 契約開始
- 契約終了
- 次期契約開始
- 次期契約終了
- 次回停止申請期限
- 次回更新停止申請日
- ステータス
- 契約中、契約更新停止申請中、契約解除、契約更新処理中
- バッチ状態管理テーブル
- バッチの二重実行の防止
- 冪等性の確保のための設計
- 複合ユニーク制約の作成バッチ実行日時+ID
- ステータス管理
- 失敗、成功、保留、実行中
- バッチ設計
- 契約更新バッチ
- 次回更新停止申請日がNULLでない
- 次回更新停止申請日が次回更新停止申請期限より前である
- ステータスを契約更新処理中に
- ステータスを契約解除に
- 次回更新停止申請期限を次期契約終了日の一ヶ月前に更新
- 次期契約開始日を契約開始日にコピー etc
- チケット補充バッチ
- 契約している分のチケットを追加する
0 件のコメント:
コメントを投稿