サブスクリプション、残高、価格プランの変更の処理[終了]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 序文 私の目的は、サブスクリプションを管理するために、複数のプロジェクト用の再利用可能なコードを作成し（そしてgithubで公開することです）。ストライプと定期請求プロバイダーについては知っていますが、このモジュールが目指しているのはそれではありません。アカウントの残高を計算するためのラッパー/ヘルパー、サブスクリプションを更新するための簡単な通知、および価格計算を処理するための単なるラッパー/ヘルパーでなければなりません。 プロバイダーまたは支払いの可能性が不十分またはまったくサポートされていないか、高額すぎる（マイクロペイメント）ため、繰り返し請求を使用できない国があります。また、定期的な請求を使用したくないが、年末に請求書を手動で支払う/請求書を保存する人もいます。したがって、PayPalの定期的な請求、繰り返しまたは同様のサービスを提案しないでください。 状況 サブスクリプションプランにサブスクライブできるモデルがあるとします（例：）User。このモデルには、現在サブスクライブしているサブスクリプションプランの識別子を格納するフィールドがあります。そのため、計画が変更されるたびに、変更が記録されます。 SubscriptionPlanChanges前述の変更を記録する次のフィールドを持つモデル（など）があります。 subscriberサブスクライブモデルに関連する（Userこの場合） from_plan モデルが変更前に持っていたプラン識別子を定義する to_plan モデルが現在選択しているプラン識別子を定義する created_at 変更を保存する日時フィールドです valid_until 実際のサブスクリプションが有効になるまで日付を保存します paid_at また、サブスクリプションが支払われたかどうか（およびいつ支払われたか）を定義する日時フィールドです。 もちろん、そのレイアウトは議論可能です。 アカウント残高の質問 ユーザーがサブスクリプションプランを変更する場合、プランフィールドを比較し、価格を取得し、現在のプランvalid_untilとその価格に基づいて新しいプランの控除を計算する必要があります。説明：プランAの1年間をサブスクライブしましたが、6か月後にプランBにアップグレードすると、プランAの6か月の支払額の半分が差し引かれます。 私が不思議に思っているのは、ユーザーが無料プランに切り替える場合など、ユーザーが再度切り替えたい場合に控除できるクレジットを持っていることです。その値を追加のフィールドにキャッシュするか、そのユーザーに関連するすべてのレコードを毎回計算しますか？テーブルのレイアウトについて何か追加/変更しますか？ わかりやすさの質問 サブスクリプション期間の終わりが来ると、ユーザーは通知を受け取り、再度支払うことでサブスクリプションを更新する可能性があります。最も簡単な方法は、更新するだけpaid_atでvalid_until、新しいサブスクリプションオプションを使用することです。ただし、支払い/購読履歴など、誰かが必要とする可能性のあるすべてのデータを保存するかどうかはわかりません。 別のオプションは、このための追加レコードを作成するだろうfrom_planとto_plan（したがって、「変化なし」を象徴しない）同じ識別子を持っているし。しかし、それは何らかの形で口座残高の計算を妨げませんか？ そのようなサブスクリプションを処理するロジックについて誰かが私を正しい方向に向けることができたら、とても感謝しています。 更新 今では助けてくれてありがとう。私の質問はあまりにも曖昧だったので、抽象化を少なくして、より正確になろうと思います。残念ながら、まだ問題を解決できませんでした。 ケースA Userはを選択できますSubscription Plan A。これは現在SubscriptionPlanChange、それを追跡するために保存されます。たとえば5か月後User、サブスクリプションをにアップグレードしますSubscription Plan B。そのため、彼は新しいサブスクリプションの価格を支払い、未使用の7か月のプランaの価格を差し引きます。 ケースB 3か月後、User彼のに戻りSubscription Plan Aます。彼は支払いをする必要はありませんが、残高を受け取るので、サブスクリプションの終了時に、彼は新しいサブスクリプションのためにその残高を差し引きます。 ケースC Userでは、独立したサブスクリプションプランを持つサブサービスのサブスクリプションプランを選択できます。同じでCase A、Case Bそのサブサービスのサブスクリプションに適用できます。 _Case D_ ユーザーがサブスクリプションの1つをキャンセルします。これにより、彼のバランスが回復します。 私の質問（少なくとも現在）は、主にそのデータを適切に保存する方法に依存しているので、ビジネス分析のためにサブスクリプションの履歴を再現し、残高を計算し、サブスクリプションに基づいて未払いを得ることができます。 また、ユーザーモデル自体などに残高を保存する必要があるかどうか、または保存されていないが保存されたデータ/履歴に基づいていつでも計算できるかどうかもわかりません。 注意すべき点がいくつかありますが、問題が発生することはないと思います。 …