會員訂閱模組的迭代
對我自己做的平台型CMS，會員訂閱這部分一直是「簡單實作」。這個週末重新對這部分做了架構，並把核心部分開發完成。
一、方式
會員訂閱，一般來說，主要包含：會員訂閱方案及購買、會員權限控制、會員管理三個部分。
1、對於會員訂閱方案及購買
準備基於已有的商城系統做一些擴展即可。
2、對於會員權限控制，
這個要特別說一下，不打算基於角色權限系統來做，而是單獨做一個會員控制的系統。
基於角色權限系統，把會員做成一個角色系列，把每個會員做成這個角色系列的角色。聽起來，似乎很合理。但是，這樣的話，無論做起來還是用起來，都特別麻煩，尤其是業務比較多的時候，各種邏輯會很複雜，一不小心就會造成各種混亂。並且也不夠靈活。
而且，實際上，很多優秀的系統的會員訂閱部分，也不會基於角色。而是基於「標記」或基於訂單來實現權限控制。包含wordpress的許多賣得很好的會員訂閱類的外掛都是這樣來做的。
基於「用戶標記」：
本質上，其實和角色系統原理一樣。就是定義一些會員的“標記”，購買了與這個“標記”關聯的會員訂閱計劃的用戶會被“打上這個標記”，這樣就能實現會員權限的控制。
以訂單為基礎：
購買會員訂閱計劃，形成訂單，付款後，將到期時間寫入訂單。所以，就可以根據訂單來判斷用戶是否是會員、是哪一種會員，以及是否已過期。這樣就可以對控制會員權限。
之前曾經做過基於訂單的方式，這次打算基於”用戶標記“。
基於訂單並沒有什麼不好，只不過，我現在做的這個平台型CMS的訂單系統支持的訂單類型比較多，造成訂單模型比較”龐大“，不打算再給它”增加體重“了，所以選擇基於”用戶標記“。
3、會員管理
基於現有的使用者管理擴展，不打算單獨做會員管理。
二、適用場景
1.基本場景
整個產品有一個或幾個訂閱計劃，用戶購買，享受會員服務。
全域定義會員標記，每一種會員標記至少包含name、slug、關聯的訂閱計畫id，三個欄位。
當使用者購買了某個會員標記的訂閱計劃，此會員標記和到期時間就會寫入此使用者的meta資料中。
2、平台/多租戶場景
對於平台和做多租戶SAAS，有一個很重要的場景：供應商自己提供的訂閱方案。
在供應商的使用者的meta資料中定義此供應商的會員標記，供應商的會員標記的key和全域會員標記的key不能相同。
當用戶購買了此供應商的訂閱方案後，相應的會員標記和到期日期就會寫入到購買用戶的meta資料中。
這次的迭代只實現基本場景即可，但要能擴展到平台和多租戶場景。
三、登入時判斷會員是否到期
使用者登入時判斷是否到期，如果到期，更新meta資料中的會員標記為false、到期日為false。
