Xử lý đăng ký, số dư và thay đổi kế hoạch giá [đóng]

Lời mở đầu
Mục đích của tôi là tạo mã có thể tái sử dụng cho nhiều dự án (và cũng xuất bản nó trên github) để quản lý đăng ký. Tôi biết về các nhà cung cấp thanh toán sọc và định kỳ, nhưng đó không phải là điều mà mô-đun này hướng tới. Nó chỉ nên là một trình bao bọc / người trợ giúp để tính toán số dư tài khoản, thông báo dễ dàng để gia hạn đăng ký và xử lý các tính toán giá.

Có những quốc gia bạn không thể sử dụng thanh toán định kỳ do nhà cung cấp hoặc khả năng thanh toán có kém hoặc không có hỗ trợ cho nó hoặc quá đắt (micropayments). Và có những người không muốn sử dụng thanh toán định kỳ mà thanh toán hóa đơn theo cách thủ công / avingg một hóa đơn vào cuối năm. Vì vậy, vui lòng không đề xuất thanh toán định kỳ paypal, dịch vụ định kỳ hoặc tương tự.

Tình huống
Giả sử bạn có một mô hình có thể đăng ký gói thuê bao (ví dụ User). Mô hình này có một trường lưu trữ định danh của gói thuê bao mà nó hiện đang đăng ký. Vì vậy, trên mỗi thay đổi kế hoạch, thay đổi được ghi lại.

Có một mô hình (ví dụ SubscriptionPlanChanges) với các trường sau ghi lại các thay đổi được đề cập:

• subscriberliên quan đến mô hình đăng ký ( Usertrong trường hợp này)
• from_plan xác định định danh kế hoạch mà mô hình đã có trước khi thay đổi
• to_plan xác định định danh kế hoạch mà mô hình đã chọn bây giờ
• created_at là trường thời gian lưu trữ thay đổi
• valid_until lưu trữ ngày cho đến khi đăng ký thực tế là hợp lệ
• paid_at cũng là trường ngày giờ xác định đăng ký nếu (và khi nào) được thanh toán

Tất nhiên, bố trí đó là thảo luận.

Câu hỏi về số dư tài khoản
Khi Người dùng thay đổi gói đăng ký của mình, tôi cần so sánh các trường của gói, lấy giá và tính khoản khấu trừ cho gói mới dựa trên giá của gói hiện tại valid_until. Nói: Bạn đã đăng ký một năm của kế hoạch A nhưng sau 6 tháng, bạn nâng cấp lên kế hoạch B, do đó bạn được khấu trừ một nửa giá phải trả cho 6 tháng của kế hoạch A.

Điều tôi băn khoăn: Nếu một người dùng ví dụ chuyển sang gói miễn phí, anh ta có một khoản tín dụng có thể được khấu trừ nếu người dùng muốn chuyển đổi lại. Bạn có lưu trữ giá trị đó trong một trường bổ sung hoặc tính toán thông qua tất cả các bản ghi liên quan đến người dùng đó mỗi lần không? Bạn sẽ thêm / thay đổi một cái gì đó về cách bố trí bảng?

Câu hỏi về tính dễ hiểu
Khi kết thúc thời hạn đăng ký, người dùng sẽ được thông báo và có khả năng gia hạn đăng ký của mình bằng cách thanh toán lại. Cách dễ nhất sẽ là chỉ cập nhật paid_atvà valid_untilvới các tùy chọn đăng ký mới. Tuy nhiên, tôi không chắc chắn nếu bạn lưu trữ mọi dữ liệu mà ai đó có thể cần, như lịch sử thanh toán / đăng ký.

Một lựa chọn khác là tạo một bản ghi bổ sung cho điều này, trong đó from_planvà to_plancó cùng một mã định danh (do đó tượng trưng cho "không thay đổi"). Nhưng điều đó có cản trở việc tính toán số dư tài khoản theo một cách nào đó không?

Nếu ai đó có thể chỉ cho tôi đi đúng hướng về logic xử lý các đăng ký như vậy, tôi sẽ đánh giá cao nó rất nhiều.

CẬP NHẬT
Cảm ơn sự giúp đỡ của bây giờ. Tôi nghĩ rằng câu hỏi của tôi quá mơ hồ nên tôi sẽ cố gắng chính xác hơn bằng cách sử dụng ít trừu tượng hơn. Thật không may, tôi chưa thể giải quyết vấn đề của mình.

Trường hợp A
User có thể chọn Subscription Plan A. Điều này hiện đang lưu trữ SubscriptionPlanChangeđể theo dõi nó. Sau 5 tháng, Usernâng cấp thuê bao của anh ấy lên Subscription Plan B. Vì vậy, anh ta trả giá cho thuê bao mới của mình, trừ đi giá của gói a trong 7 tháng không sử dụng.

Trường hợp B
Sau 3 tháng, Userlăn lại chỗ của mình Subscription Plan A. Anh ta không phải trả tiền nhưng nhận được số dư cho nó, khi kết thúc đăng ký, anh ta được khấu trừ số dư đó cho đăng ký mới của mình.

Trường hợp C
User có thể chọn gói thuê bao cho dịch vụ phụ có gói thuê bao độc lập. Tương tự Case Avà Case Bcó thể áp dụng cho thuê bao dịch vụ phụ đó.

_Case D_ Người dùng hủy bỏ một trong các đăng ký của mình. Điều này dẫn đến sự cân bằng của anh ấy.

Câu hỏi của tôi (hiện tại, ít nhất) chủ yếu phụ thuộc vào cách lưu trữ dữ liệu đó đúng cách để tôi có thể sao chép lịch sử đăng ký để phân tích kinh doanh và tính toán số dư, nhận thanh toán chưa thanh toán dựa trên đăng ký, v.v.

Tôi cũng không chắc chắn liệu số dư có nên được lưu trữ hay không, ví dụ như chính mô hình người dùng hoặc nếu nó không được lưu trữ nhưng có thể được tính bất cứ lúc nào dựa trên dữ liệu / lịch sử được lưu trữ.

Một số điều cần lưu ý, mặc dù tôi không nghĩ rằng họ nên đưa ra vấn đề:

• Nó không phải là một User, nó có thể là bất cứ điều gì, đó là lý do tại sao Subscriberđa hình
• Planskhông nhất thiết phải là kế hoạch, nhưng có thể được ví dụ Magazinesnhư được đề cập. Đó là những gì tôi đã mô tả với Trường hợp C và Trường hợp D .

Thật không may, câu trả lời cho một vấn đề phức tạp thường phức tạp. Lời khuyên của tôi cho bạn là chỉ lưu thông tin liên quan, sau đó sử dụng mô hình để xây dựng bức tranh lớn hơn.

Nói cách khác, bảng của bạn, subscriptPlanChanges sẽ có các thông tin sau cho khóa của nó:

• người đăng kí
• kế hoạch
• có hiệu lực từ

Theo cách này, bạn cho phép nhiều gói cho cùng một thuê bao có thể chồng lấp. Các lĩnh vực khác bao gồm:

• có hiệu lực đến
• trả cho đến khi
• tỷ lệ (cũng 0 nếu miễn phí)

Lưu ý rằng không có "kế hoạch từ" hoặc "kế hoạch đến". Mặc dù bạn có thể có chúng, thông tin là không cần thiết và có thể tự tính toán (lưu trữ thông tin đó có nghĩa là bạn có nhiệm vụ bổ sung là giữ cho nó phù hợp). Khi một kế hoạch mới bắt đầu, thay vì phải sửa đổi các kế hoạch hiện có, bạn rời khỏi chúng và chỉ cần thêm một bản ghi mới. Nếu một kế hoạch chồng chéo khác tồn tại sau kế hoạch mới, thì bạn có thể quyết định bạn muốn xóa nó (trực quan hơn theo cách này). Khi bạn tải các gói này cho một thuê bao, bạn sắp xếp chúng theo ngày "hợp lệ từ" của chúng.

Khi bạn có được điều này, việc tính toán tín dụng của người dùng tương đối đơn giản. Nếu hai gói không thể trùng nhau, bạn chỉ cần lấy ít hơn hai ngày giữa ngày "hợp lệ cho đến" của gói trước và "hợp lệ từ" của gói hiện tại để xác định ngày kết thúc. Ngày bắt đầu là ngày lớn hơn trong hai ngày giữa ngày "hợp lệ từ" và ngày "trả cho đến khi" (nếu được xác định). Khoản thanh toán (hoặc tín dụng) sau đó có thể được tính trên tỷ lệ nhân với khoảng thời gian giữa ngày bắt đầu và ngày kết thúc được đề cập ở trên của kế hoạch đó.

Theo cách này, về lý thuyết bạn có thể tính toán bất cứ điều gì bạn cần biết. Tôi sẽ khuyên bạn không nên cố gắng lưu các giá trị được tính toán, vì nó sẽ thay đổi khi một bản ghi hiện tại được sửa đổi, thêm hoặc xóa.

Biến thể về cách bạn sẽ tính toán các giá trị này có thể được quản lý bằng cách thêm trường loại bổ sung. Trong mã của bạn, bạn có thể tạo các trình xử lý đặc biệt để quản lý logic tính toán các kế hoạch cụ thể để giữ cho thuật toán chính của bạn tương đối rõ ràng với các phép tính phức tạp. Vẫn tốt hơn nếu bạn quản lý để tạo một trình xử lý cho trường hợp không có loại nào được chỉ định, vì vậy tất cả những gì bạn phải làm là gọi trình xử lý thích hợp theo loại của nó để thực hiện bất kỳ loại tính toán nào bạn yêu cầu.

Tôi hy vọng trả lời câu hỏi của bạn.

Ngoài câu trả lời trên, tôi sẽ tạo một bảng có các khoản tín dụng, trong đó tín dụng sẽ bằng với loại tiền hiện tại. Bất cứ khi nào người dùng chuyển đổi kế hoạch sang một lựa chọn rẻ hơn, số dư chưa sử dụng sẽ nhập dưới dạng tín dụng. Bất cứ khi nào người dùng có thứ gì đó để thanh toán, bạn sẽ sử dụng khoản tín dụng trước và chỉ yêu cầu thanh toán nếu khoản tín dụng hết hoặc không tồn tại. Nếu sử dụng phương án này, hãy tạo bảng dưới dạng danh sách giao dịch để có thể tái tạo kịch bản sử dụng nếu có tranh chấp xảy ra. Thí dụ:

ID, UserId, TransactionDate, Credit (tích cực khi bạn cung cấp tín dụng người dùng và âm khi người dùng sử dụng tín dụng)

Chỉ cần tổng hợp các khoản tín dụng cho người dùng để hiển thị số dư của anh ấy / cô ấy.

Hy vọng đây là một số sử dụng cho bạn ...