구독, 잔액 및 가격 계획 변경 처리 [닫기]

서문
나의 목표는 구독을 관리하기 위해 여러 프로젝트에 재사용 가능한 코드를 만들고 (github에 게시) 것입니다. 스트라이프 및 반복 청구 제공 업체에 대해 알고 있지만 이것이이 모듈의 목표는 아닙니다. 계정 잔액 계산, 구독 갱신 알림, 가격 계산 처리를위한 래퍼 / 헬퍼 일뿐입니다.

공급자 또는 지불 지원이 없거나 지원이 없거나 너무 비싸서 (소액 결제) 반복 결제를 사용할 수없는 국가가 있습니다. 그리고 반복 결제를 사용하고 싶지 않지만 연말에 청구서를 수동으로 지불하거나 송장을 발행하는 사람들이 있습니다. 따라서 페이팔 반복 청구, 반복 또는 유사한 서비스를 제안하지 마십시오.

상황
구독 계획 (예 :)을 구독 할 수있는 모델이 있다고 가정 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 개월 동안 계획 가격을 차감합니다.

사례 B
3 개월 후로 User롤백 Subscription Plan A합니다. 그는 비용을 지불 할 필요는 없지만 잔액을 받으면 가입이 끝날 때 새 가입에 대해 잔액이 차감됩니다.

사례 C
User 는 독립적 인 가입 계획이있는 하위 서비스에 대한 가입 계획을 선택할 수 있습니다. 동일 Case A및 Case B그 하위 서비스 가입을 신청할 수 있습니다.

_Case D_ 사용자가 구독 중 하나를 취소합니다. 이것은 그의 균형을 차지합니다.

내 질문 (최소한 현재)은 주로 데이터를 올바르게 저장하는 방법에 달려 있으므로 비즈니스 분석에 대한 구독 내역을 재현하고 잔액을 계산하고 구독을 기반으로 미결제 금액을받을 수 있습니다.

또한 예를 들어 사용자 모델 자체에 잔액을 저장해야하는지 또는 저장되지 않았지만 저장된 데이터 / 이력을 기반으로 언제든지 계산할 수 있는지 잘 모르겠습니다.

나는 그들이 문제를 일으킬 것이라고 생각하지는 않지만 주목해야 할 몇 가지 사항 :

• 그것은을 할 필요가 없다 User(가) 왜 그, 그것은 아무것도 할 수 Subscriber다형성
• Plans반드시 계획 일 필요는 없지만, 예를 들어 Magazines언급 된 것과 같을 수 있습니다 . 이것이 제가 사례 C 와 사례 D에서 설명한 것입니다 .

불행히도 복잡한 문제에 대한 답은 일반적으로 복잡합니다. 내 조언은 관련 정보 만 저장 한 다음 모델을 사용하여 더 큰 그림을 만드는 것입니다.

다시 말해, 테이블 SubscriptionPlanChanges에는 해당 키에 대한 다음 정보가 있습니다.

• 구독자
• 계획
• 유효

이러한 방식으로, 동일한 가입자에 대해 여러 계획이 중복되도록 할 수 있습니다. 다른 분야는 다음과 같습니다.

• 까지 유효합니다
• 까지 지불
• 요금 (무료 인 경우 0)

"plan from"또는 "plan to"가 없습니다. 그것들을 가질 수는 있지만, 정보는 불필요하며 스스로 계산할 수 있습니다 (이러한 정보를 저장하면 정보를 일관성있게 유지하는 추가 작업이 있음을 의미합니다). 기존 계획을 수정하지 않고 새 계획이 시작되면 그대로두고 새 레코드를 추가합니다. 새 계획 이후에 겹치는 다른 계획이있는 경우 계획을 삭제하기로 결정할 수 있습니다 (이 방법은 더 직관적 임). 가입자에 대해 이러한 계획을로드하면 "유효한 날짜"날짜별로 계획을 정렬합니다.

이것을 얻은 후에는 사용자의 신용을 계산하는 것이 비교적 간단합니다. 두 계획이 겹칠 수없는 경우 종료 날짜를 결정하기 위해 이전 계획의 "유효 날짜"날짜와 현재 계획의 "유효 날짜"사이의 두 날짜 중 더 적은 날짜 만 사용하면됩니다. 시작 날짜는 "유효한"날짜와 "유료까지"날짜 (정의 된 경우) 사이의 두 날짜 중 큰 날짜입니다. 지불 (또는 크레디트)은 그 계획의 위에서 언급 한 시작 날짜와 종료 날짜 사이의 시간 간격을 곱한 요율로 계산 될 수 있습니다.

이런 식으로 이론적으로 알아야 할 것을 계산할 수 있습니다. 기존 레코드가 수정, 추가 또는 삭제 될 때 변경되므로 계산 된 값을 저장하지 않는 것이 좋습니다.

추가 유형 필드를 추가하여 이러한 값을 계산하는 방법의 변형을 관리 할 수 ​​있습니다. 코드에서 주 알고리즘에 복잡한 계산을 비교적 명확하게 유지하기 위해 특정 계획을 계산하는 논리를 관리하는 특수 처리기를 만들 수 있습니다. 유형이 지정되지 않은 경우에 대한 핸들러를 작성하여 처리해야하는 경우에는 유형에 따라 적절한 핸들러를 호출하여 필요한 계산을 수행하기 만하면됩니다.

귀하의 질문에 답변이 되었기를 바랍니다.

위의 답변 외에도 신용이 현재 통화와 같은 신용이 ​​포함 된 테이블을 만듭니다. 사용자가 더 저렴한 대안으로 전환 할 때마다 미사용 잔액이 크레딧으로 들어갑니다. 사용자가 지불 할 항목이있을 때마다 크레딧을 먼저 사용하고 크레딧이 소진되었거나 존재하지 않는 경우에만 지불을 요청합니다. 이 대안을 사용하는 경우, 분쟁이 발생할 경우 사용법 시나리오를 재현 할 수 있도록 테이블을 트랜잭션 목록으로 작성하십시오. 예:

ID, UserId, TransactionDate, Credit (사용자에게 크레딧을 제공하면 긍정적이고 사용자가 크레딧을 사용하면 부정)

잔액을 표시하기 위해 사용자의 크레딧을 합산하십시오.

이것이 당신에게 도움이되기를 바랍니다 ...