課金周りのテーブル設計について
とあるサービス開発に携わっていて課金周りの実装に悩ましさを抱えている。
具体的には 課金ユーザーが持つcustomer_idをどのようにもたせるかということだ。 toCのサービスであればユーザー=課金ユーザーなのでuserテーブルにcustomer_idを付与すればいいと思うんだが、 今回はユーザー単位の場合もあれば会社単位の場合もある、といった具合。
脳死状態で実装するとすればcompanyテーブルにcustomer_idがあり、userテーブルにもcustomer_idがあるみたいな感じになるんだが、 これはcustomer_idが点在してるのが微妙だなーと思う。
設計的には中間テーブルでcustomerテーブルとつなぐのが丸い。 companies - company_customers - customers users - user_customers - customers 的な具合。
設計的にはこれでいいんだが実はまだ問題はあって、 userがcompanyに属する場合だ。 この場合以下のようなことを検討する必要があるかなと思う。
- userとcompanyが同じものを課金する可能性があるか
- userとcompanyの二重課金を許可するか
- 課金側は何をもって課金ユーザーを一意に特定するか（たとえばemailで一意に特定する場合、サービス側でuserとcompanyが同じemailを持っていたらどうなるかなど）
なにはともあれ外部の課金サービスでAPI叩いている場合などは、 自分のサービス側で課金情報を適切に保持してしっかりとsyncすることがまずは重要かなと思う。
